Date: Mon, 9 Jul 2001 09:16:49 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <Pine.SUN.3.91.1010709084741.15060B-100000@pcnet1.pcnet.com> In-Reply-To: <3B49794F.5123170F@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Jul 2001, Julian Elischer wrote: > Jason Evans wrote: > > > > On Sun, Jul 08, 2001 at 10:51:19PM -0700, Julian Elischer wrote: > > > Can someone tell me if an alarm() call that sets an alarm signal for > > > some time in the futire (in a threaded environment, has teh signal delivered > > > to the process (an random thread), the same thread that made the request, > > > or a predesignated thread.. I just can't work out > > > what the right way to handle it in the code is.. > > > > > > posix? > > > > Bwahaha, signals and threads. > > > > Each thread has its own signal mask. A signal sent to the process is > > delivered to a thread that doesn't have the signal masked (if any). If > > more than one thread has the signal unmasked, which thread receives the > > signal is undefined. > > > > That's what happens (or is supposed to happen). If you want to know the > > right way to do signal handling in threaded programs, that requires more > > explanation. > > here's where I'm having problems... > I can pass the signal to the UTS, but I don't know what to do about the > threads that are doing 'uninterruptable sleeps' in the kernel. > Should the UTS give me back a list of threads to kick? > that would satisfy the posix semantics. The UTS needs tell the kernel to interrupt a specific blocked thread. If the ksectx is not interruptable at its current point, then the kernel needs to mark it as having a signal pending on it so that the signal handler (or upcall) can be called when it either becomes interruptable or is ready to return to userland. The UTS cannot deliver the signal until the kernel tells it that the ksectx is either interruptable or completed. I'm not quite sure what happens in a normal trampoline; if a signal handler completes normally, does it go back to the same spot in the kernel to finish its work (assume SA_RESTART is set)? If so, I think the interrupted ksectx needs to be set to the current ksectx when the interruption occurs. The UTS has no idea whether the invoked signal handler is going to return normally or not. (If the signal handler longjmps out of the handler, you need to make sure the ksectx isn't left forever in the kernel.) > I guess I should ignore all signals when in KSE mode and just pass them up > as an upcall. > (The kernel interface and the user interface need not be the same). > > This indicates that a signal pre-empts whatever is running to do an upcall > rather than > waiting until i gets a chance that may never happen. > (hmmmmm I need to think about this more... off to bed..) On a related note, the UTS needs another system call to send a message from one KSE to another (possibly set of) KSEs. The UTS does direct handoff of mutexes, condition variables, and other things. If the handoff is to a thread running (now waiting) on another KSE or KSEG, then the we need to be able to "signal" it that that thread should now be runnable. A similar thing for signals. If the thread that needs the signal dispatched is scheduled on another KSE, then we need to send that KSE a message to inform it of that. I say "possibly set of" KSEs because of pthread_cond_broadcast(). -- 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.1010709084741.15060B-100000>