| Summary: | ASTERISK-02832: Retry poll() on EINTR in ast_waitfor_nandfds() | ||
| Reporter: | jcomellas (jcomellas) | Labels: | |
| Date Opened: | 2004-11-16 10:57:02.000-0600 | Date Closed: | 2011-06-07 14:10:04 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) channel_poll_retry_on_eintr.patch | |
| Description: | Asterisk modules that raise Unix signals cause the waits for ast_waitfor_nandfs() to exit with an error. We found this problem with a module that instances a Java Virtual Machine. This is normal for the JVM, because it uses the SIGUSR1 and SIGUSR2 signals to handle I/O interruption. The problem is that if you're constantly raising signals the ast_waitfor_nandfds() API becomes practically useless. I made a patch to channel.c to retry the poll() if the system call is interrupted by a signal, which I'm attaching to this message. The main difference with the original version is that in case of an EINTR it now retries the poll() whereas previously it returned as if there had been a timeout. ****** ADDITIONAL INFORMATION ****** The patch includes a similar change to ast_waitfor_n_fd(). | ||
| Comments: | By: Mark Spencer (markster) 2004-11-16 16:58:18.000-0600 Asterisk depends upon the behavior that things back out when the signal is interrupted and this functionality is required for reliable Masquerade functionality. In any case, java should interface as a separate process since (unless you have a GPL java interpreter) linking to a java library, interpreter, etc. would be in violation of GPL without an exception from Digium. | ||