Re: A signal fairy tale
Jamie wrote: > Daniel R. Kegel wrote: > > Christopher Smith <[EMAIL PROTECTED]> wrote: > > > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > > > Btw, this functionality is already available using sigaction(). Just > > > > search for a signal whose handler is SIG_DFL. If you then block that > > > > signal before changing, checking the result, and unblocking the signal, > > > > you can avoid race conditions too. (This is what my programs do). > > > > > > It's more than whether a signal is blocked or not, unfortunately. Lots of > > > applications will invoke sigwaitinfo() on whatever the current signal mask > > > is, which means you can't rely on sigaction to solve your problems. :-( > > > > As Chris points out, allocating a signal by the scheme Jamie > > describes is neccessary but not sufficient. The problem Chris > > ran into is that he allocated a signal fair and square, only to find > > the application picking it up via sigwaitinfo()! > > I check that the handler is not SIG_DFL, but perhaps my assumption that > any sigwaitinfo() user of a signal would set SA_SIGINFO and set the > handler to non-SIG_DFL is mistaken? I think your assumption is correct. The problem is that the application in question (Sun's JDK 1.4 beta) does something like this: sigprocmask(0, NULL, ); sigwaitinfo(, ); So even though Chris did set the handler for his signal to non-SIG_DFL, the application didn't care, and sucked all his signal notifications away from him. > > Yes, this is a bug in the application -- but it's interesting that this > > bug only shows up when you try to integrate a new, well-behaved, library > > into the app. It's a fragile part of the Unix API. sigopen() is > > a way for libraries to defend themselves against misuse of sigwaitinfo() > > by big applications over which you have no control. > > > > So sigopen() is a technological fix to a social problem, I guess. > > Requiring all libraries to use the sigopen() as you specified it just > isn't going to work, because you would have to make big changes to the > libraries. I didn't mean to require any library to change at all. This is an optional thing; a library can use this technique if it wants to insulate itself from badly behaved applications. > Sometimes you actually do need SIGRTxxx signals to be delivered using > signal handlers! No objection there, I agree. > Also as it was specified, you are reduced to reading one type of signal > at a time, or using select(). Often you wish to check several signals. > For example, in my programs sigwaitinfo() calls check for SIGIO, SIGURG > and SIGRTxxx at least. Therefore siginfo(), if implemented, should take > a sigset_t, not a signal number. I have no objection to sigopen() taking a sigset_t *. > The problem of when you actually want to receive an allocated signal > through a handler is, IMHO, best solved by permitting sigaction() and > signal delivery on signals that have been opened with sigopen(). sigopen() essentially installs a special signal handler (say, SIG_OPEN). If sigaction() can override that, it should probably close the file descriptor, too. I can buy that, perhaps, even though it makes libraries using sigopen() somewhat more vulnerable to poorly behaved applications. I think the present application doesn't misbehave badly enough that it would try to install a signal handler over Chris's. > However, it would be ok to require a flag SA_SIGOPEN to sigaction() to > prevent it from returning EBUSY. That'd be ok. Another issue someone raised: > would read() on this fd require the kernel to copy every byte of the siginfo_t? IMHO no; read() would leave undefined any bytes that would not have been set by sigwaitinfo(). The kernel could set them to zero or leave them untouched, as desired. Another issue: AFAIK, there's no 'read with a timeout' system call for file descriptors, so if you needed the equivalent of sigtimedwait(), you might end up doing a select on the sigopen fd, which is an extra system call. (I wish Posix had invented sigopen() and readtimedwait() instead of sigtimedwait...) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Jamie wrote: Daniel R. Kegel wrote: Christopher Smith [EMAIL PROTECTED] wrote: Jamie Lokier [EMAIL PROTECTED] wrote: Btw, this functionality is already available using sigaction(). Just search for a signal whose handler is SIG_DFL. If you then block that signal before changing, checking the result, and unblocking the signal, you can avoid race conditions too. (This is what my programs do). It's more than whether a signal is blocked or not, unfortunately. Lots of applications will invoke sigwaitinfo() on whatever the current signal mask is, which means you can't rely on sigaction to solve your problems. :-( As Chris points out, allocating a signal by the scheme Jamie describes is neccessary but not sufficient. The problem Chris ran into is that he allocated a signal fair and square, only to find the application picking it up via sigwaitinfo()! I check that the handler is not SIG_DFL, but perhaps my assumption that any sigwaitinfo() user of a signal would set SA_SIGINFO and set the handler to non-SIG_DFL is mistaken? I think your assumption is correct. The problem is that the application in question (Sun's JDK 1.4 beta) does something like this: sigprocmask(0, NULL, oldset); sigwaitinfo(oldset, info); So even though Chris did set the handler for his signal to non-SIG_DFL, the application didn't care, and sucked all his signal notifications away from him. Yes, this is a bug in the application -- but it's interesting that this bug only shows up when you try to integrate a new, well-behaved, library into the app. It's a fragile part of the Unix API. sigopen() is a way for libraries to defend themselves against misuse of sigwaitinfo() by big applications over which you have no control. So sigopen() is a technological fix to a social problem, I guess. Requiring all libraries to use the sigopen() as you specified it just isn't going to work, because you would have to make big changes to the libraries. I didn't mean to require any library to change at all. This is an optional thing; a library can use this technique if it wants to insulate itself from badly behaved applications. Sometimes you actually do need SIGRTxxx signals to be delivered using signal handlers! No objection there, I agree. Also as it was specified, you are reduced to reading one type of signal at a time, or using select(). Often you wish to check several signals. For example, in my programs sigwaitinfo() calls check for SIGIO, SIGURG and SIGRTxxx at least. Therefore siginfo(), if implemented, should take a sigset_t, not a signal number. I have no objection to sigopen() taking a sigset_t *. The problem of when you actually want to receive an allocated signal through a handler is, IMHO, best solved by permitting sigaction() and signal delivery on signals that have been opened with sigopen(). sigopen() essentially installs a special signal handler (say, SIG_OPEN). If sigaction() can override that, it should probably close the file descriptor, too. I can buy that, perhaps, even though it makes libraries using sigopen() somewhat more vulnerable to poorly behaved applications. I think the present application doesn't misbehave badly enough that it would try to install a signal handler over Chris's. However, it would be ok to require a flag SA_SIGOPEN to sigaction() to prevent it from returning EBUSY. That'd be ok. Another issue someone raised: would read() on this fd require the kernel to copy every byte of the siginfo_t? IMHO no; read() would leave undefined any bytes that would not have been set by sigwaitinfo(). The kernel could set them to zero or leave them untouched, as desired. Another issue: AFAIK, there's no 'read with a timeout' system call for file descriptors, so if you needed the equivalent of sigtimedwait(), you might end up doing a select on the sigopen fd, which is an extra system call. (I wish Posix had invented sigopen() and readtimedwait() instead of sigtimedwait...) - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Christopher Smith <[EMAIL PROTECTED]> wrote: > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > Btw, this functionality is already available using sigaction(). Just > > search for a signal whose handler is SIG_DFL. If you then block that > > signal before changing, checking the result, and unblocking the signal, > > you can avoid race conditions too. (This is what my programs do). > > It's more than whether a signal is blocked or not, unfortunately. Lots of > applications will invoke sigwaitinfo() on whatever the current signal mask > is, which means you can't rely on sigaction to solve your problems. :-( As Chris points out, allocating a signal by the scheme Jamie describes is neccessary but not sufficient. The problem Chris ran into is that he allocated a signal fair and square, only to find the application picking it up via sigwaitinfo()! Yes, this is a bug in the application -- but it's interesting that this bug only shows up when you try to integrate a new, well-behaved, library into the app. It's a fragile part of the Unix API. sigopen() is a way for libraries to defend themselves against misuse of sigwaitinfo() by big applications over which you have no control. So sigopen() is a technological fix to a social problem, I guess. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
From: Christopher Smith <[EMAIL PROTECTED]> >> [ sigopen() proposal ] >... From a programming standpoint, this >looks like a really nice approach. I must say I prefer this approach to the >various "event" strategies I've seen to date, as it fixes the primary >problem with signals, while still allowing us to hook in to all the >standard POSIX API's that already use signals. Thanks. I'm sure people already thought of this long ago, it's basically just the usual "In Unix, everything's a file". Until you ran into that problem where the jvm was stealing your signals, though, I hadn't seen a situation where having signals behave like files would be important. >It'd be nice if I could pass >in a 0 for signum and have the kernel select from unused signals (problem >being that "unused" is not necessarily easy to define), althouh I guess an >inefficient version of this could be handled in userland. There is a (non-threadsafe) convention that Jamie Lokier pointed out for finding an unused thread. If we allowed sigopen(-1) to allocate a new signal for you, it'd probably just use the same scheme... >I presume the fd could be shared between threads and otherwise behave like >a normal fd, which would be sper nice. Yes. >I guess the main thing I'm thinking is this could require some significant >changes to the way the kernel behaves. Still, it's worth taking a "try it >and see approach". If anyone else thinks this is a good idea I may hack >together a sample patch and give it a whirl. What's the biggest change you see? From my (two-martini-lunch-tainted) viewpoint, it's just another kind of signal masking, sorta... >Thanks again good fairy Dan/Eunice. ;-) You're welcome (and I'll tell Eunice you liked her idea!). - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Balbir Singh <[EMAIL PROTECTED]> wrote: >Shouldn't there be a sigclose() and other operations to make the API >orthogonal. No, plain old close() on the file descriptor returned by sigopen() would do the trick. >sigopen() should be selective about the signals it allows >as argument. Try and make sigopen() thread specific, so that if one >thread does a sigopen(), it does not imply it will do all the signal >handling for all the threads. IMHO sigopen()/read() should behave just like sigwait() with respect to threads. That means that in Posix, it would not be thread specific, but in Linux, it would be thread specific, because that's how signals and threads work there at the moment. >Does using sigopen() imply that signal(), sigaction(), etc cannot be used. >In the same process one could do a sigopen() in the library, but the >process could use sigaction()/signal() without knowing what the library >does (which signals it handles, etc). Between sigopen() and close(), calling signal() or sigaction() on that signal would probably return EBUSY. A well-behaved program already looks for an unoccupied signal using sigaction (as Jamie Lokier points out), so they shouldn't try to reuse a signal in use by sigopen(). - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Balbir Singh [EMAIL PROTECTED] wrote: Shouldn't there be a sigclose() and other operations to make the API orthogonal. No, plain old close() on the file descriptor returned by sigopen() would do the trick. sigopen() should be selective about the signals it allows as argument. Try and make sigopen() thread specific, so that if one thread does a sigopen(), it does not imply it will do all the signal handling for all the threads. IMHO sigopen()/read() should behave just like sigwait() with respect to threads. That means that in Posix, it would not be thread specific, but in Linux, it would be thread specific, because that's how signals and threads work there at the moment. Does using sigopen() imply that signal(), sigaction(), etc cannot be used. In the same process one could do a sigopen() in the library, but the process could use sigaction()/signal() without knowing what the library does (which signals it handles, etc). Between sigopen() and close(), calling signal() or sigaction() on that signal would probably return EBUSY. A well-behaved program already looks for an unoccupied signal using sigaction (as Jamie Lokier points out), so they shouldn't try to reuse a signal in use by sigopen(). - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
From: Christopher Smith [EMAIL PROTECTED] [ sigopen() proposal ] ... From a programming standpoint, this looks like a really nice approach. I must say I prefer this approach to the various event strategies I've seen to date, as it fixes the primary problem with signals, while still allowing us to hook in to all the standard POSIX API's that already use signals. Thanks. I'm sure people already thought of this long ago, it's basically just the usual In Unix, everything's a file. Until you ran into that problem where the jvm was stealing your signals, though, I hadn't seen a situation where having signals behave like files would be important. It'd be nice if I could pass in a 0 for signum and have the kernel select from unused signals (problem being that unused is not necessarily easy to define), althouh I guess an inefficient version of this could be handled in userland. There is a (non-threadsafe) convention that Jamie Lokier pointed out for finding an unused thread. If we allowed sigopen(-1) to allocate a new signal for you, it'd probably just use the same scheme... I presume the fd could be shared between threads and otherwise behave like a normal fd, which would be sper nice. Yes. I guess the main thing I'm thinking is this could require some significant changes to the way the kernel behaves. Still, it's worth taking a try it and see approach. If anyone else thinks this is a good idea I may hack together a sample patch and give it a whirl. What's the biggest change you see? From my (two-martini-lunch-tainted) viewpoint, it's just another kind of signal masking, sorta... Thanks again good fairy Dan/Eunice. ;-) You're welcome (and I'll tell Eunice you liked her idea!). - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Christopher Smith [EMAIL PROTECTED] wrote: Jamie Lokier [EMAIL PROTECTED] wrote: Btw, this functionality is already available using sigaction(). Just search for a signal whose handler is SIG_DFL. If you then block that signal before changing, checking the result, and unblocking the signal, you can avoid race conditions too. (This is what my programs do). It's more than whether a signal is blocked or not, unfortunately. Lots of applications will invoke sigwaitinfo() on whatever the current signal mask is, which means you can't rely on sigaction to solve your problems. :-( As Chris points out, allocating a signal by the scheme Jamie describes is neccessary but not sufficient. The problem Chris ran into is that he allocated a signal fair and square, only to find the application picking it up via sigwaitinfo()! Yes, this is a bug in the application -- but it's interesting that this bug only shows up when you try to integrate a new, well-behaved, library into the app. It's a fragile part of the Unix API. sigopen() is a way for libraries to defend themselves against misuse of sigwaitinfo() by big applications over which you have no control. So sigopen() is a technological fix to a social problem, I guess. - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: scheduling callbacks in user space triggered via kernel....
Ashok wrote: > Is there a method to schedule user mode code from > kernel agent? ... > windows 2000 offers 2 such facilities. (APC or async > procedure calls) where a thread can block and when > ready will be woken via the kernel agent and can run a > user supplied function. > > or a method to bind a function to a file handle, when > there is Completed IO, the kernel would call the > registered function with a parameter of the buffer > submitted for IO. The traditional Unix way might be for user process to call one of the blocking functions (read(), poll(), sigwait(), etc), and have the kernel unblock the process in the usual way. There is support for real async I/O on the horizon; see the SGI patch at http://oss.sgi.com/projects/kaio/ if you need async I/O today. Not sure this is what you're after, though. Can you provide an example of how you want to use this? For those who haven't read about this NT stuff, see http://www.microsoft.com/msj/0499/pooling/pooling.htm Even AS/400 is getting into this stuff; see http://www.as400.ibm.com/developer/v4r5/api.html - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: scheduling callbacks in user space triggered via kernel....
Ashok wrote: Is there a method to schedule user mode code from kernel agent? ... windows 2000 offers 2 such facilities. (APC or async procedure calls) where a thread can block and when ready will be woken via the kernel agent and can run a user supplied function. or a method to bind a function to a file handle, when there is Completed IO, the kernel would call the registered function with a parameter of the buffer submitted for IO. The traditional Unix way might be for user process to call one of the blocking functions (read(), poll(), sigwait(), etc), and have the kernel unblock the process in the usual way. There is support for real async I/O on the horizon; see the SGI patch at http://oss.sgi.com/projects/kaio/ if you need async I/O today. Not sure this is what you're after, though. Can you provide an example of how you want to use this? For those who haven't read about this NT stuff, see http://www.microsoft.com/msj/0499/pooling/pooling.htm Even AS/400 is getting into this stuff; see http://www.as400.ibm.com/developer/v4r5/api.html - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
Andrea Arcangeli wrote: > Petru Paler wrote: > > This is one of the main thttpd design points: run in a select() loop. Since > > it is intended for mainly static workloads, it performs quite well... > > It can't scale in SMP. thttpd is i/o bound, not CPU bound, so there's no need for SMP scaling. It's an effective little server as long as the active document tree fits in RAM. If it ain't broke, don't tell people how to fix it :-) (If for some reason SMP scaling was desirable, the thttpd way to do it would be to introduce one thread for each CPU, and have each thread run the same select() loop.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
Andrea Arcangeli wrote: Petru Paler wrote: This is one of the main thttpd design points: run in a select() loop. Since it is intended for mainly static workloads, it performs quite well... It can't scale in SMP. thttpd is i/o bound, not CPU bound, so there's no need for SMP scaling. It's an effective little server as long as the active document tree fits in RAM. If it ain't broke, don't tell people how to fix it :-) (If for some reason SMP scaling was desirable, the thttpd way to do it would be to introduce one thread for each CPU, and have each thread run the same select() loop.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
