From owner-freebsd-questions Mon Oct 23 15:59: 2 2000 Delivered-To: freebsd-questions@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1831237B479 for ; Mon, 23 Oct 2000 15:59:00 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9NMwxZ12844; Mon, 23 Oct 2000 15:58:59 -0700 (PDT) Date: Mon, 23 Oct 2000 15:58:59 -0700 From: Alfred Perlstein To: Flemming Froekjaer Cc: freebsd-questions@freebsd.org Subject: Re: SIG codes > 128 allowed? Message-ID: <20001023155858.W28123@fw.wintelcom.net> References: <641C2F90.19430A3A.0F2A144B@netscape.net> <20001023130415.U28123@fw.wintelcom.net> <0963B774.2A753185.0F2A144B@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <0963B774.2A753185.0F2A144B@netscape.net>; from froekjaerf@netscape.net on Mon, Oct 23, 2000 at 06:13:53PM -0400 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Flemming Froekjaer [001023 15:14] wrote: > > Alfred Perlstein wrote: > > > > * Flemming Froekjaer [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