Messages in this thread | | | Date | Thu, 29 Jul 1999 17:08:19 -0600 | From | yodaiken@chelm ... | Subject | Re: [RFC] RT signals |
| |
On Thu, Jul 29, 1999 at 11:40:56AM -0700, Richard Henderson wrote: > On Thu, Jul 29, 1999 at 08:07:40AM -0600, yodaiken@chelm.cs.nmt.edu wrote: > > How about making sigque simply send a message to a socket? > > This could be done at library level. All we'd need is hooks to do a > > sigaction on messages on that queue which would be useful anyways. > > You are thinking way too hard how to keep all functionality > at user level. You should try to implement such a thing and > find out how bloody awful it would be.
I'm not proposing keeping all functionality at the kernel. What I'm proposing is that an existing mechanism for delivering data between processes should be made more powerful instead of adding a complex new mechanism. And, more generally, I'm arguing that if POSIX says "call K does Z" that does not necessarily mean the kernel needs system call K. Instead of using POSIX as a reason to put yet more junk in the kernel, we should (A) evaluate which POSIX functionality really needs to be in the kernel, and (B) what POSIX functionality can be obtained by improvements using the current API.
So, POSIX says sigqueue must send this goofy structure. Well, we have a generic problem with select that is more important than POSIX -- because real applications depend on it. Perhaps we can provide signal(SIG_ASYNC_NOTIFY,handler) fd = open("/proc/myid/posix_signals",2); ioctl(fd,SIG_NOTIFY,...)
handler: read(fd,&message,size) if message.type== POSIX_RT_SIGNAL ...
Maybe that's a stupid idea. But I bet there is some elegant method for making the system better instead of just bigger.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |