Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Jul 2001 08:11:08 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Jason Evans <jasone@canonware.com>
Cc:        Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG
Subject:   Re: help needed in threads.. (Signals)
Message-ID:  <Pine.SUN.3.91.1010711080525.15505B-100000@pcnet1.pcnet.com>
In-Reply-To: <20010710212453.E22464@canonware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Jul 2001, Jason Evans wrote:
> On Tue, Jul 10, 2001 at 08:29:46PM -0700, Julian Elischer wrote:
> 
> > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets 
> > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload())
> 
> Yes, there are separare handlers per thread.  However, I think this is
> strictly a concern of the UTS, isn't it?

I don't think this is true, at least that's not the way it currently
is implemented in libc_r.  But even if there were to be separate
handlers per thread, I agree that it can be handled by the UTS.

> > 3/ Is it possible that each thread has a mask but that the handlers are
>   shared?
> 
> That would be evil programming practice, but AFAIK, nothing should prevent
> a program from doing that.

Actually, this is the way it works now.  The only evil thing is
trying to get more than 1 thread to handle the same signal.

> > Certainly If you are nominating a thread to take each kind of interrupt
> > then it makes no sense to have per-thread values for these.
> 
> Proper programming practice says that at most one thread should have a
> particular signal unmasked.  Furthermore, it is generally best to use
> sigwait(3).

Yes!

> > What semantics are we looking for?
> 
> POSIX.  If you don't already have a copy of Butenhof's "Programming with
> POSIX Threads", get a copy; it's a wonderful book.

You can also get a copy of the draft Austin (new POSIX) spec by
registering as a reviewer (www.opengroup.org).  There are more
requirements that affect threads in there :(

-- 
Dan Eischen

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010711080525.15505B-100000>