Re: A signal fairy tale
Just to confirm Dan. I was a fool and did not install the dummy handler for the masked signal I was using. I added the proper code over the weekend with no noticable effect (JDK 1.3 still sigtimedwait()'s on the signal :-(). --Chris - 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
Just to confirm Dan. I was a fool and did not install the dummy handler for the masked signal I was using. I added the proper code over the weekend with no noticable effect (JDK 1.3 still sigtimedwait()'s on the signal :-(). --Chris - 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
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: > At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: > >life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation > >into queued, information-carrying siginfo signals just shows how badly we > >need a more robust event model... (what would truly kick butt is a unified > >interface that could deliver everything from fd events to AIO completions to > >semaphore/msgqueue events, etc, with explicit binding between event queues > >and threads). > > I guess this is my thinking: it's really not that much of a stretch to make > signals behave like GetMessage(). Indeed, sigopen() brings them > sufficiently close. By doing this, you DO provide this unified interface > for all the different types of events you described which works much like > GetMessage(). So, but adding a couple of syscalls you avoid having to > implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. Wouldn't recv/recvfrom/recvmsg suffice? I think they could do the trick. More covenience functions can than be derived in userland library. You still have one type of events per descriptor, but you can combine with poll in userspace library. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> - 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
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation into queued, information-carrying siginfo signals just shows how badly we need a more robust event model... (what would truly kick butt is a unified interface that could deliver everything from fd events to AIO completions to semaphore/msgqueue events, etc, with explicit binding between event queues and threads). I guess this is my thinking: it's really not that much of a stretch to make signals behave like GetMessage(). Indeed, sigopen() brings them sufficiently close. By doing this, you DO provide this unified interface for all the different types of events you described which works much like GetMessage(). So, but adding a couple of syscalls you avoid having to implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. Wouldn't recv/recvfrom/recvmsg suffice? I think they could do the trick. More covenience functions can than be derived in userland library. You still have one type of events per descriptor, but you can combine with poll in userspace library. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] - 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
Dan Kegel wrote: > Pseudocode: > > sigemptyset(); > sigaddset(SIGUSR1, ); > fd=sigopen(); > m=read(fd, buf, n*sizeof(siginfo_t)) > close(fd); > > should probably be equivalent to > > sigemptyset(); > sigaddset(SIGUSR1, ); > struct sigaction newaction, oldaction; > newaction.sa_handler = dummy_handler; > newaction.sa_flags = SA_SIGINFO; > newaction.sa_mask = 0; > sigaction(SIGUSR1, , ); I forgot to mask off the signal to avoid traditional delivery: sigprocmask(SIG_BLOCK, , ); > for (i=0; i if (sigwaitinfo(, buf+i)) > break; > m = n * sizeof(siginfo_t); > sigaction(SIGUSR1, , 0); sigprocmask(SIG_UNBLOCK, ); > (apologies if any of the above is wrong) - 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
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: > P.S.: What do you mean by explicit binding between event queues and > threads? I'm not sure I see what this gains you. Cache affinity presumably? --cw - 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]> writes: [...] > >Signals are a pretty dopey API anyway - so instead of trying to > >patch them up, why not think of something better for AIO? > > You assume that this issue only comes up when you're doing AIO. If > we do something that makes signals work better, we can have a much > broader impact that just AIO. If nothing else, the signal usage > clashing issue has nothing to do with AIO. So what. Signals are bad system already. Therefore don't try to force them to do more stuff. Just because they have already been forced to do more doesn't mean it was a good idea at all, or that we should keep on patching bits and pieces onto them, IMHO. -- http://ape.n3.net - 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 wrote: > > At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote: > >From: Christopher Smith <[EMAIL PROTECTED]> > > >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... > > Yeah, the more I think about it, the more I think this is just another > branch in the signal delivery code. Not necessarily too huge a change. I'll > hack on this over the weekend I think. Cool, have fun! Feature checklist for future reference: If sigopen() has been called, and the file descriptor is still open, sigaction(x, 0, ) should show foo != SIG_DFL for compatibility with the traditional signal allocation scheme. If sigopen() has been called, and the file descriptor is still open, sending a signal to the thread (or if posix, the process) that called sigopen() should cause the signal to stick until picked up by read(), or until close() is called on the fd(), in which case it will be delivered or picked up as normal. sigaction(x, , 0) should return EBUSY if fd=sigopen(x) has been called but close(fd) has not yet been called. Pseudocode: sigemptyset(); sigaddset(SIGUSR1, ); fd=sigopen(); m=read(fd, buf, n*sizeof(siginfo_t)) close(fd); should probably be equivalent to sigemptyset(); sigaddset(SIGUSR1, ); struct sigaction newaction, oldaction; newaction.sa_handler = dummy_handler; newaction.sa_flags = SA_SIGINFO; newaction.sa_mask = 0; sigaction(SIGUSR1, , ); for (i=0; ihttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Christopher Smith wrote: > > At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote: > >Balbir Singh <[EMAIL PROTECTED]> wrote: > > >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. > > Actually, I believe with IBM's new Posix threads implementation, Linux > finally does signal delivery "the right way". In general, I think it'd be > nice if this API *always* sucked up signals from all threads. This makes > sense particularly since the FD is accessible by all threads. Although I'm looking forward to the day when Linux threading (perhaps thanks to IBM's enhancements to Gnu Pth) becomes Posix compliant, for now we need to consider both Posix threads and LinuxThreads. I think the proper behavior for sigopen() under the two threading systems would be: Posix threads: sigopen() would capture signals delivered to the process, as well as signals delivered by pthread_kill() to the thread that called sigopen(). Current LinuxThreads: sigopen() would only capture signals delivered to the thread that called 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
At 01:11 PM 6/28/2001 -0700, Daniel R. Kegel wrote: >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...) What, you don't want to use AIO or to collect your AIO signals? ;-) In my apps, what I'd do is spawn a few worker threads which would do blocking reads. Particularly if the sigopen() API allows me to grab multiple signals from one fd, this should work well enough for one's high performance needs. Alternatively, one could use select/poll to check if there was data ready before doing the read. I agree though that it'd be nice to have a timed read. --Chris - 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
At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: >life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation >into queued, information-carrying siginfo signals just shows how badly we >need a more robust event model... (what would truly kick butt is a unified >interface that could deliver everything from fd events to AIO completions to >semaphore/msgqueue events, etc, with explicit binding between event queues >and threads). I guess this is my thinking: it's really not that much of a stretch to make signals behave like GetMessage(). Indeed, sigopen() brings them sufficiently close. By doing this, you DO provide this unified interface for all the different types of events you described which works much like GetMessage(). So, but adding a couple of syscalls you avoid having to implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. --Chris P.S.: What do you mean by explicit binding between event queues and threads? I'm not sure I see what this gains you. - 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
At 01:58 PM 6/28/2001 +0100, John Fremlin wrote: > Dan Kegel <[EMAIL PROTECTED]> writes: > >A signal number cannot be opened more than once concurrently; > >sigopen() thus provides a way to avoid signal usage clashes > >in large programs. >Signals are a pretty dopey API anyway - so instead of trying to patch >them up, why not think of something better for AIO? You assume that this issue only comes up when you're doing AIO. If we do something that makes signals work better, we can have a much broader impact that just AIO. If nothing else, the signal usage clashing issue has nothing to do with AIO. --Chris - 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
At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote: >Balbir Singh <[EMAIL PROTECTED]> wrote: > >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. Actually, I believe with IBM's new Posix threads implementation, Linux finally does signal delivery "the right way". In general, I think it'd be nice if this API *always* sucked up signals from all threads. This makes sense particularly since the FD is accessible by all threads. --Chris - 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 - a little comphist
At 03:57 PM 6/28/2001 +0200, Heusden, Folkert van wrote: >[...] > >A signal number cannot be opened more than once concurrently; > >sigopen() thus provides a way to avoid signal usage clashes > >in large programs. >YOU> Signals are a pretty dopey API anyway - > >Exactly. When signals were made up, signalhandlers were supposed to >not so much more then a last cry and then exit the application. sigHUP >to re-read the config was not supposed to happen. > >YOU> so instead of trying to patch >YOU> them up, why not think of something better for AIO? > >Yeah, a select() on excepfds. POSIX AIO API's are significantly more powerful then using select(), particularly for certain types of applications. select() doesn't provide you with a good way to perform I/O operations at different offsets simultaneously, doesn't allow for I/O priority, etc. --Chris - 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
At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote: >From: Christopher Smith <[EMAIL PROTECTED]> > >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... Yeah, the more I think about it, the more I think this is just another branch in the signal delivery code. Not necessarily too huge a change. I'll hack on this over the weekend I think. --Chris - 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
At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote: Balbir Singh [EMAIL PROTECTED] wrote: 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. Actually, I believe with IBM's new Posix threads implementation, Linux finally does signal delivery the right way. In general, I think it'd be nice if this API *always* sucked up signals from all threads. This makes sense particularly since the FD is accessible by all threads. --Chris - 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 - a little comphist
At 03:57 PM 6/28/2001 +0200, Heusden, Folkert van wrote: [...] A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. YOU Signals are a pretty dopey API anyway - Exactly. When signals were made up, signalhandlers were supposed to not so much more then a last cry and then exit the application. sigHUP to re-read the config was not supposed to happen. YOU so instead of trying to patch YOU them up, why not think of something better for AIO? Yeah, a select() on excepfds. POSIX AIO API's are significantly more powerful then using select(), particularly for certain types of applications. select() doesn't provide you with a good way to perform I/O operations at different offsets simultaneously, doesn't allow for I/O priority, etc. --Chris - 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
At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote: From: Christopher Smith [EMAIL PROTECTED] 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... Yeah, the more I think about it, the more I think this is just another branch in the signal delivery code. Not necessarily too huge a change. I'll hack on this over the weekend I think. --Chris - 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
At 01:58 PM 6/28/2001 +0100, John Fremlin wrote: Dan Kegel [EMAIL PROTECTED] writes: A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? You assume that this issue only comes up when you're doing AIO. If we do something that makes signals work better, we can have a much broader impact that just AIO. If nothing else, the signal usage clashing issue has nothing to do with AIO. --Chris - 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
At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation into queued, information-carrying siginfo signals just shows how badly we need a more robust event model... (what would truly kick butt is a unified interface that could deliver everything from fd events to AIO completions to semaphore/msgqueue events, etc, with explicit binding between event queues and threads). I guess this is my thinking: it's really not that much of a stretch to make signals behave like GetMessage(). Indeed, sigopen() brings them sufficiently close. By doing this, you DO provide this unified interface for all the different types of events you described which works much like GetMessage(). So, but adding a couple of syscalls you avoid having to implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. --Chris P.S.: What do you mean by explicit binding between event queues and threads? I'm not sure I see what this gains you. - 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
At 01:11 PM 6/28/2001 -0700, Daniel R. Kegel wrote: 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...) What, you don't want to use AIO or to collect your AIO signals? ;-) In my apps, what I'd do is spawn a few worker threads which would do blocking reads. Particularly if the sigopen() API allows me to grab multiple signals from one fd, this should work well enough for one's high performance needs. Alternatively, one could use select/poll to check if there was data ready before doing the read. I agree though that it'd be nice to have a timed read. --Chris - 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 wrote: At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote: Balbir Singh [EMAIL PROTECTED] wrote: 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. Actually, I believe with IBM's new Posix threads implementation, Linux finally does signal delivery the right way. In general, I think it'd be nice if this API *always* sucked up signals from all threads. This makes sense particularly since the FD is accessible by all threads. Although I'm looking forward to the day when Linux threading (perhaps thanks to IBM's enhancements to Gnu Pth) becomes Posix compliant, for now we need to consider both Posix threads and LinuxThreads. I think the proper behavior for sigopen() under the two threading systems would be: Posix threads: sigopen() would capture signals delivered to the process, as well as signals delivered by pthread_kill() to the thread that called sigopen(). Current LinuxThreads: sigopen() would only capture signals delivered to the thread that called 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
Christopher Smith wrote: At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote: From: Christopher Smith [EMAIL PROTECTED] 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... Yeah, the more I think about it, the more I think this is just another branch in the signal delivery code. Not necessarily too huge a change. I'll hack on this over the weekend I think. Cool, have fun! Feature checklist for future reference: If sigopen() has been called, and the file descriptor is still open, sigaction(x, 0, foo) should show foo != SIG_DFL for compatibility with the traditional signal allocation scheme. If sigopen() has been called, and the file descriptor is still open, sending a signal to the thread (or if posix, the process) that called sigopen() should cause the signal to stick until picked up by read(), or until close() is called on the fd(), in which case it will be delivered or picked up as normal. sigaction(x, foo, 0) should return EBUSY if fd=sigopen(x) has been called but close(fd) has not yet been called. Pseudocode: sigemptyset(s); sigaddset(SIGUSR1, s); fd=sigopen(s); m=read(fd, buf, n*sizeof(siginfo_t)) close(fd); should probably be equivalent to sigemptyset(s); sigaddset(SIGUSR1, s); struct sigaction newaction, oldaction; newaction.sa_handler = dummy_handler; newaction.sa_flags = SA_SIGINFO; newaction.sa_mask = 0; sigaction(SIGUSR1, newaction, oldaction); for (i=0; in; i++) if (sigwaitinfo(s, buf+i)) break; m = n * sizeof(siginfo_t); sigaction(SIGUSR1, oldaction, 0); (apologies if any of the above is wrong) But, um, Chris, could you check your library code to make sure you did the sigaction stuff? Could it be that you forgot that, and if you did that properly, the main application would notice that you'd allocated a signal, and not suck up your signals? - 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] writes: [...] Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? You assume that this issue only comes up when you're doing AIO. If we do something that makes signals work better, we can have a much broader impact that just AIO. If nothing else, the signal usage clashing issue has nothing to do with AIO. So what. Signals are bad system already. Therefore don't try to force them to do more stuff. Just because they have already been forced to do more doesn't mean it was a good idea at all, or that we should keep on patching bits and pieces onto them, IMHO. -- http://ape.n3.net - 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
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: P.S.: What do you mean by explicit binding between event queues and threads? I'm not sure I see what this gains you. Cache affinity presumably? --cw - 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
Dan Kegel wrote: Pseudocode: sigemptyset(s); sigaddset(SIGUSR1, s); fd=sigopen(s); m=read(fd, buf, n*sizeof(siginfo_t)) close(fd); should probably be equivalent to sigemptyset(s); sigaddset(SIGUSR1, s); struct sigaction newaction, oldaction; newaction.sa_handler = dummy_handler; newaction.sa_flags = SA_SIGINFO; newaction.sa_mask = 0; sigaction(SIGUSR1, newaction, oldaction); I forgot to mask off the signal to avoid traditional delivery: sigprocmask(SIG_BLOCK, s, oldmask); for (i=0; in; i++) if (sigwaitinfo(s, buf+i)) break; m = n * sizeof(siginfo_t); sigaction(SIGUSR1, oldaction, 0); sigprocmask(SIG_UNBLOCK, s); (apologies if any of the above is wrong) - 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, ); 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
John Fremlin wrote: > >A signal number cannot be opened more than once concurrently; > >sigopen() thus provides a way to avoid signal usage clashes > >in large programs. > > Signals are a pretty dopey API anyway - so instead of trying to patch > them up, why not think of something better for AIO? Keep in mind that SIGRTxxx signals are not just used for AIO. -- Jamie - 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
> admit that UNIX has a crappy event model, and implement something like Win32 > GetMessage =)... Thats a subset of the real time signal model already in Linux. Just block the signal and wait for it.. - 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
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? > 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. Sometimes you actually do need SIGRTxxx signals to be delivered using signal handlers! 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. 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(). However, it would be ok to require a flag SA_SIGOPEN to sigaction() to prevent it from returning EBUSY. :-) -- Jamie - 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
> Signals are a pretty dopey API anyway - so instead of trying to patch > them up, why not think of something better for AIO? I have to agree, in a way... At some point we need to swallow our pride, admit that UNIX has a crappy event model, and implement something like Win32 GetMessage =)... I've been having trouble finding situations where asynchronous signals are really the most appropriate technique, aside from delivering life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation into queued, information-carrying siginfo signals just shows how badly we need a more robust event model... (what would truly kick butt is a unified interface that could deliver everything from fd events to AIO completions to semaphore/msgqueue events, etc, with explicit binding between event queues and threads). Regards, 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 - a little comphist
[...] >A signal number cannot be opened more than once concurrently; >sigopen() thus provides a way to avoid signal usage clashes >in large programs. YOU> Signals are a pretty dopey API anyway - Exactly. When signals were made up, signalhandlers were supposed to not so much more then a last cry and then exit the application. sigHUP to re-read the config was not supposed to happen. YOU> so instead of trying to patch YOU> them up, why not think of something better for AIO? Yeah, a select() on excepfds. - 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
Dan Kegel <[EMAIL PROTECTED]> writes: [...] >A signal number cannot be opened more than once concurrently; >sigopen() thus provides a way to avoid signal usage clashes >in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? [...] -- http://ape.n3.net - 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
Dan Kegel [EMAIL PROTECTED] writes: [...] A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? [...] -- http://ape.n3.net - 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 - a little comphist
[...] A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. YOU Signals are a pretty dopey API anyway - Exactly. When signals were made up, signalhandlers were supposed to not so much more then a last cry and then exit the application. sigHUP to re-read the config was not supposed to happen. YOU so instead of trying to patch YOU them up, why not think of something better for AIO? Yeah, a select() on excepfds. - 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
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? 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. Sometimes you actually do need SIGRTxxx signals to be delivered using signal handlers! 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. 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(). However, it would be ok to require a flag SA_SIGOPEN to sigaction() to prevent it from returning EBUSY. :-) -- Jamie - 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
Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? I have to agree, in a way... At some point we need to swallow our pride, admit that UNIX has a crappy event model, and implement something like Win32 GetMessage =)... I've been having trouble finding situations where asynchronous signals are really the most appropriate technique, aside from delivering life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation into queued, information-carrying siginfo signals just shows how badly we need a more robust event model... (what would truly kick butt is a unified interface that could deliver everything from fd events to AIO completions to semaphore/msgqueue events, etc, with explicit binding between event queues and threads). Regards, 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
John Fremlin wrote: A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? Keep in mind that SIGRTxxx signals are not just used for AIO. -- Jamie - 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
admit that UNIX has a crappy event model, and implement something like Win32 GetMessage =)... Thats a subset of the real time signal model already in Linux. Just block the signal and wait for it.. - 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
| |> Let me know, when somebody has a patch or needs help, I would like to |> help or take a look at it. | |Maybe we can both hack on this. | Sure, that should be interesting, did you have something in mind ? We can start right away. - 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
--On Wednesday, June 27, 2001 11:18:28 +0200 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. :-( --Chris - 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
--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > Shouldn't there be a sigclose() and other operations to make the API Wouldn't the existing close() be good enough for that? > orthogonal. 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. Actually, this is exactly what you do want to happen. Linux's existing signals + threads semantics are not exactly ideal for high-performance computing. Of course, fd's are shared by all threads, so all of the threads would be able to read the siginfo structures into memory. > 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). If I understood Dan's intentions correctly, you could use signal() and sigaction(), but while the fd is open, signals would be queued up to the fd rather than passed off to a signal handler or sigwaitinfo(). Care to comment Dan? > Let me know, when somebody has a patch or needs help, I would like to > help or take a look at it. Maybe we can both hack on this. --Chris - 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
Dan Kegel wrote: >That signal is no longer delivered normally or available for >pickup with sigwait() et al. Instead, it must be picked up by >calling read() on the file descriptor returned by sigwait(); >the buffer passed to read() must have a size which is a >multiple of sizeof(siginfo_t). Does this mean that the read() call must write sizeof(siginfo_t) bytes for each signal delivered? At the moment, the kernel does not have to write the whole siginfo_t structure to userspace -- it can write just those fields which are relevant for a particular signal. >A signal number cannot be opened more than once concurrently; >sigopen() thus provides a way to avoid signal usage clashes in >large programs. sigopen() won't prevent signal usage clashes if the other user is using sigaction() and sigtimedwait(), or will it? 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). -- Jamie - 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
Dan Kegel wrote: That signal is no longer delivered normally or available for pickup with sigwait() et al. Instead, it must be picked up by calling read() on the file descriptor returned by sigwait(); the buffer passed to read() must have a size which is a multiple of sizeof(siginfo_t). Does this mean that the read() call must write sizeof(siginfo_t) bytes for each signal delivered? At the moment, the kernel does not have to write the whole siginfo_t structure to userspace -- it can write just those fields which are relevant for a particular signal. A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. sigopen() won't prevent signal usage clashes if the other user is using sigaction() and sigtimedwait(), or will it? 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). -- Jamie - 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
--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh [EMAIL PROTECTED] wrote: Shouldn't there be a sigclose() and other operations to make the API Wouldn't the existing close() be good enough for that? orthogonal. 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. Actually, this is exactly what you do want to happen. Linux's existing signals + threads semantics are not exactly ideal for high-performance computing. Of course, fd's are shared by all threads, so all of the threads would be able to read the siginfo structures into memory. 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). If I understood Dan's intentions correctly, you could use signal() and sigaction(), but while the fd is open, signals would be queued up to the fd rather than passed off to a signal handler or sigwaitinfo(). Care to comment Dan? Let me know, when somebody has a patch or needs help, I would like to help or take a look at it. Maybe we can both hack on this. --Chris - 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
--On Wednesday, June 27, 2001 11:18:28 +0200 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. :-( --Chris - 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: A signal fairy tale
| | Let me know, when somebody has a patch or needs help, I would like to | help or take a look at it. | |Maybe we can both hack on this. | Sure, that should be interesting, did you have something in mind ? We can start right away. - 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
Shouldn't there be a sigclose() and other operations to make the API orthogonal. 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. 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). Let me know, when somebody has a patch or needs help, I would like to help or take a look at it. Balbir |NAME | sigopen - open a signal as a file descriptor | |SYNOPSIS | #include | | int sigopen(int signum); | |DESCRIPTION | The sigopen system call opens signal number signum as a file descriptor. | That signal is no longer delivered normally or available for pickup | with sigwait() et al. Instead, it must be picked up by calling | read() on the file descriptor returned by sigwait(); the buffer passed to | read() must have a size which is a multiple of sizeof(siginfo_t). | Multiple signals may be picked up with a single call to read(). | When that file descriptor is closed, the signal is available once more | for traditional use. | A signal number cannot be opened more than once concurrently; sigopen() | thus provides a way to avoid signal usage clashes in large programs. | |RETURN VALUE | signal returns the new file descriptor, or -1 on error (in which case, errno | is set appropriately). | |ERRORS | EWOULDBLOCK signal is already open | |NOTES | read() will block when reading from a file descriptor opened by sigopen() | until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called | to set it into nonblocking mode. | |HISTORY | sigopen() first appeared in the 2.5.2 Linux kernel. | |Linux July, 2001 1 | - 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
--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel <[EMAIL PROTECTED]> wrote: > Once upon a time a hacker named Xman > wrote a library that used aio, and decided > to use sigtimedwait() to pick up completion > notifications. It worked well, and his I/O > was blazing fast (since was using a copy > of Linux that was patched to have good aio). > But when he tried to integrate his library > into a large application someone else had > written, woe! that application's use of signals > conflicted with his library. "Fsck!" said Xman. > At that moment a fairy appeared, and said > "Young man, watch your language, or I'm going to > have to turn you into a goon! I'm the good fairy Eunice. > Can I help you?" Xman explained his problem to Eunice, > who smiled and said "All you need is right here, > just type 'man 2 sigopen'". Xman did, and saw: I must thank the god fair Eunice. ;-) 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. 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. I presume the fd could be shared between threads and otherwise behave like a normal fd, which would be sper nice. 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. Thanks again good fairy Dan/Eunice. ;-) --Chris - 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/
A signal fairy tale
Once upon a time a hacker named Xman wrote a library that used aio, and decided to use sigtimedwait() to pick up completion notifications. It worked well, and his I/O was blazing fast (since was using a copy of Linux that was patched to have good aio). But when he tried to integrate his library into a large application someone else had written, woe! that application's use of signals conflicted with his library. "Fsck!" said Xman. At that moment a fairy appeared, and said "Young man, watch your language, or I'm going to have to turn you into a goon! I'm the good fairy Eunice. Can I help you?" Xman explained his problem to Eunice, who smiled and said "All you need is right here, just type 'man 2 sigopen'". Xman did, and saw: SIGOPEN(2)Linux Programmer's Manual SIGOPEN(2) NAME sigopen - open a signal as a file descriptor SYNOPSIS #include int sigopen(int signum); DESCRIPTION The sigopen system call opens signal number signum as a file descriptor. That signal is no longer delivered normally or available for pickup with sigwait() et al. Instead, it must be picked up by calling read() on the file descriptor returned by sigwait(); the buffer passed to read() must have a size which is a multiple of sizeof(siginfo_t). Multiple signals may be picked up with a single call to read(). When that file descriptor is closed, the signal is available once more for traditional use. A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. RETURN VALUE signal returns the new file descriptor, or -1 on error (in which case, errno is set appropriately). ERRORS EWOULDBLOCK signal is already open NOTES read() will block when reading from a file descriptor opened by sigopen() until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called to set it into nonblocking mode. HISTORY sigopen() first appeared in the 2.5.2 Linux kernel. Linux July, 2001 1 When he finished reading, he knew just how to solve his problem, and he lived happily ever after. The End. - 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/
A signal fairy tale
Once upon a time a hacker named Xman wrote a library that used aio, and decided to use sigtimedwait() to pick up completion notifications. It worked well, and his I/O was blazing fast (since was using a copy of Linux that was patched to have good aio). But when he tried to integrate his library into a large application someone else had written, woe! that application's use of signals conflicted with his library. Fsck! said Xman. At that moment a fairy appeared, and said Young man, watch your language, or I'm going to have to turn you into a goon! I'm the good fairy Eunice. Can I help you? Xman explained his problem to Eunice, who smiled and said All you need is right here, just type 'man 2 sigopen'. Xman did, and saw: SIGOPEN(2)Linux Programmer's Manual SIGOPEN(2) NAME sigopen - open a signal as a file descriptor SYNOPSIS #include signal.h int sigopen(int signum); DESCRIPTION The sigopen system call opens signal number signum as a file descriptor. That signal is no longer delivered normally or available for pickup with sigwait() et al. Instead, it must be picked up by calling read() on the file descriptor returned by sigwait(); the buffer passed to read() must have a size which is a multiple of sizeof(siginfo_t). Multiple signals may be picked up with a single call to read(). When that file descriptor is closed, the signal is available once more for traditional use. A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. RETURN VALUE signal returns the new file descriptor, or -1 on error (in which case, errno is set appropriately). ERRORS EWOULDBLOCK signal is already open NOTES read() will block when reading from a file descriptor opened by sigopen() until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called to set it into nonblocking mode. HISTORY sigopen() first appeared in the 2.5.2 Linux kernel. Linux July, 2001 1 When he finished reading, he knew just how to solve his problem, and he lived happily ever after. The End. - 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
--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel [EMAIL PROTECTED] wrote: Once upon a time a hacker named Xman wrote a library that used aio, and decided to use sigtimedwait() to pick up completion notifications. It worked well, and his I/O was blazing fast (since was using a copy of Linux that was patched to have good aio). But when he tried to integrate his library into a large application someone else had written, woe! that application's use of signals conflicted with his library. Fsck! said Xman. At that moment a fairy appeared, and said Young man, watch your language, or I'm going to have to turn you into a goon! I'm the good fairy Eunice. Can I help you? Xman explained his problem to Eunice, who smiled and said All you need is right here, just type 'man 2 sigopen'. Xman did, and saw: I must thank the god fair Eunice. ;-) 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. 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. I presume the fd could be shared between threads and otherwise behave like a normal fd, which would be sper nice. 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. Thanks again good fairy Dan/Eunice. ;-) --Chris - 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
Shouldn't there be a sigclose() and other operations to make the API orthogonal. 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. 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). Let me know, when somebody has a patch or needs help, I would like to help or take a look at it. Balbir |NAME | sigopen - open a signal as a file descriptor | |SYNOPSIS | #include signal.h | | int sigopen(int signum); | |DESCRIPTION | The sigopen system call opens signal number signum as a file descriptor. | That signal is no longer delivered normally or available for pickup | with sigwait() et al. Instead, it must be picked up by calling | read() on the file descriptor returned by sigwait(); the buffer passed to | read() must have a size which is a multiple of sizeof(siginfo_t). | Multiple signals may be picked up with a single call to read(). | When that file descriptor is closed, the signal is available once more | for traditional use. | A signal number cannot be opened more than once concurrently; sigopen() | thus provides a way to avoid signal usage clashes in large programs. | |RETURN VALUE | signal returns the new file descriptor, or -1 on error (in which case, errno | is set appropriately). | |ERRORS | EWOULDBLOCK signal is already open | |NOTES | read() will block when reading from a file descriptor opened by sigopen() | until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called | to set it into nonblocking mode. | |HISTORY | sigopen() first appeared in the 2.5.2 Linux kernel. | |Linux July, 2001 1 | - 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/
