Re: A signal fairy tale

Re: A signal fairy tale

[Daniel R. Kegel]

Balbir Singh <balbir.singh@wipro.com> 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

Re: A signal fairy tale

[Christopher Smith]

At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
>Balbir Singh <balbir.singh@wipro.com> 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

Re: A signal fairy tale

[Dan Kegel]

Christopher Smith wrote:
> 
> At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >Balbir Singh <balbir.singh@wipro.com> 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

Re: A signal fairy tale

[Dan Maas]

> 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

Re: A signal fairy tale

[Alan Cox]

> 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..

Re: A signal fairy tale

[Christopher Smith]

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.

Re: A signal fairy tale

[Chris Wedgwood]

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

Re: A signal fairy tale

[Jan Hudec]

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 <bulb@ucw.cz>

Re: A signal fairy tale

[Daniel R. Kegel]

Jamie wrote:
> Daniel R. Kegel wrote:
> > Christopher Smith <x@xman.org> wrote:
> > > Jamie Lokier <lk@tantalophile.demon.co.uk> 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

Re: A signal fairy tale

[Christopher Smith]

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

Re: A signal fairy tale

[Daniel R. Kegel]

Christopher Smith <x@xman.org> wrote:

> Jamie Lokier <lk@tantalophile.demon.co.uk> 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

Re: A signal fairy tale

[Jamie Lokier]

Daniel R. Kegel wrote:
> Christopher Smith <x@xman.org> wrote:
> > Jamie Lokier <lk@tantalophile.demon.co.uk> 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

Re: A signal fairy tale

[Daniel R. Kegel]

From: Christopher Smith <x@xman.org>
>> [ 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.

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

Re: A signal fairy tale

[Christopher Smith]

At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
>From: Christopher Smith <x@xman.org>
> >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

Re: A signal fairy tale

[Dan Kegel]

Christopher Smith wrote:
> 
> At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >From: Christopher Smith <x@xman.org>
> > >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; i<n; 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

Re: A signal fairy tale

[Dan Kegel]

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; i<n; 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

Re: A signal fairy tale

[Christopher Smith]

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

A signal fairy tale

[Dan Kegel]

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

Re: A signal fairy tale

[Christopher Smith]

--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel <dank@kegel.com> 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 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.

Thanks again good fairy Dan/Eunice. ;-)

--Chris

Re: A signal fairy tale

[Balbir Singh]

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           
|

Re: A signal fairy tale

[Christopher Smith]

--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh 
<balbir.singh@wipro.com> 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

Re: A signal fairy tale

[Balbir Singh]

|
|> 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.

Re: A signal fairy tale

[Jamie Lokier]

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

Re: A signal fairy tale

[Christopher Smith]

--On Wednesday, June 27, 2001 11:18:28 +0200 Jamie Lokier 
<lk@tantalophile.demon.co.uk> 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

Re: A signal fairy tale

[John Fremlin]

	Dan Kegel <dank@kegel.com> 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

Re: A signal fairy tale

[Jamie Lokier]

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

Re: A signal fairy tale

[Christopher Smith]

At 01:58 PM 6/28/2001 +0100, John Fremlin wrote:
>         Dan Kegel <dank@kegel.com> 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

Re: A signal fairy tale

[John Fremlin]

Christopher Smith <x@xman.org> 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