Date: Mon, 23 Oct 2000 15:58:59 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Flemming Froekjaer <froekjaerf@netscape.net> Cc: freebsd-questions@freebsd.org Subject: Re: SIG codes > 128 allowed? Message-ID: <20001023155858.W28123@fw.wintelcom.net> In-Reply-To: <0963B774.2A753185.0F2A144B@netscape.net>; from froekjaerf@netscape.net on Mon, Oct 23, 2000 at 06:13:53PM -0400 References: <641C2F90.19430A3A.0F2A144B@netscape.net> <20001023130415.U28123@fw.wintelcom.net> <0963B774.2A753185.0F2A144B@netscape.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Flemming Froekjaer <froekjaerf@netscape.net> [001023 15:14] wrote:
>
> Alfred Perlstein <bright@wintelcom.net> wrote:
> >
> > * Flemming Froekjaer <froekjaerf@netscape.net> [001023 12:35] wrote:
> > > In signal.h, more precisely the struct __siginfo, si_code is defined as
> an
> > > integer, but the same include file also defines the constant _SIG_MAXSIG,
> > > with a value of 128. Does this mean that FreeBSD won't allow signal codes
> > > above 128, or can you use the whole positive spectrum of an integer?
> > >
> > > The reason I ask is that I want to define a sighandler for every thread
> in a
> > > process. As you may know, threads share the parent process' signal
> handlers,
> > > so I'll need a unique signal code for each thread. I anticipate that the
> > > number of threads per process will be about a thousand.
> >
> > You'll want to find a better way to dispatch to each thread than to do
> > this. You can use pthread_kill(3) to send a signal to a particular
> > thread.
>
> At first I thought I'd overlooked something, but after doing some research
> I've come to the conclusion that this still won't do it. You can send the
> signal to a particular thread, alright, but if more than one thread has
> unblocked that particular signal, it will subsequently be very difficult to
> determine which thread the signal was directed at. Furthermore, the
> process-level signal handler must block the signal in question while handling
> it.
This can be solved a number of ways, one that comes to mind is
using pthread_setspecific(3) and pthread_getspecific(3) to implement
your switch for what the signal means to each thread.
> What I aim for is true thread-level asynchronous I/O. I want independant,
> event-driven threads, basically, where each thread has it's own signal
> handler which can be invoked, regardless of process states, at any given time.
> Now, if I can safely use signals outside the kernel-defined range, all my
> problems will be solved. I just assign a unique signal - and consequently a
> unique signal handler - to each thread.
Each thread can also register it's own handler afaik, this means
that one can avoid the use of pthread_getspecific(3).
Btw, you can't do this, from src/sys/kern_sig.c:
int
kill(cp, uap)
register struct proc *cp;
register struct kill_args *uap;
{
register struct proc *p;
if ((u_int)uap->signum > _SIG_MAXSIG)
return (EINVAL);
sorry.
> I'd love to use processes for this, but I'm afraid those are too costly for
> this application. The need for speed and all that...
Using processes can work, but it makes IPC more costly and inconvient.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001023155858.W28123>