[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A signal fairy tale
From: Christopher Smith <>
>> [ 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 sooooper 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.

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.043 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site