Re: Problem killing my threads :)
Re: Problem killing my threads :)
- Subject: Re: Problem killing my threads :)
- From: "Ken Thomases" <email@hidden>
- Date: Thu, 26 Sep 2002 08:06:40 -0500
- Priority: normal
On 23 Sep 2002, at 12:58, Guillaume Outters <email@hidden> wrote:
>
>
Le lundi 23 septembre 2002, ` 20:57 PM, Aram Greenman a icrit :
>
>
> I *think* the operation would always be atomic if the variable assigned
>
> to was a single-byte type (i.e. char), but I'm not sure.
>
>
I based my assumption on the fact that for this kind of flag, he just
>
needs one bit being set (and read back by the thread). And I think that
>
on any computer since, well let's tell 1946, the bit is atomic :-)
See my other message on this thread about why this doesn't matter.
>
The effective problem is when to do detection; if the thread is some
>
kind of runloop with blocking system calls (NSRunLoop or select or
>
poll), doing so won't resolve the question. There will be some need of
>
either a periodic verification using timers in runloop or timeouts for
>
select, or to have a "communication channel" between both threads, like
>
DO or a pipe watched by the poll(), that can "awake" the thread.
Yes. Important point. If the worker thread ever uses blocking
system calls, the main thread needs a reliable way to kick it out of
those system calls.
>
Oh, BTW, could Unix guys tell me if a signal would ensure any
>
select()/poll() on any thread exits with an EINTR?
Unfortunately, signals inducing EINTR are _not_ the "reliable way" we
need. Yes, it is usually possible to configure the environment so
that system calls exit with EINTR when a signal is received by the
thread (see "man sigaction" and look for SA_RESTART). However, that
leaves us with a race condition. The signal might be delivered
immediately before the worker thread enters select(). That wouldn't
cause the call to select() to fail to block; as soon as the worker
thread exits the signal handler and is scheduled to run it will
happily enter select() and block there.
One might argue that they'll check the shouldTerminate variable just
before entering select() so either shouldTerminate will be non-zero
and select() won't be entered or select() will be entered and the
signal will wake it. Remember, I said the signal might be delivered
_immediately_ before entering select(). The worker thread might be
just about to execute the JSR instruction (Jump to SubRoutine, or
similar) when the scheduler switches it out and the main thread in.
The main thread will set shouldTerminate and raise a signal for the
worker thread. When worker thread is next scheduled, it will handle
the signal. It's not yet in select(), so no special select-aborting
action will occur. After the signal handler returns, the worker
thread resumes at the JSR into select(). It's past the point where
it can check shouldTerminate to avoid the call -- entering select()
is inevitable at this point. Now your worker thread is blocked until
select() returns for any of the normal reasons (fd readable,
writable, exceptional, or timeout).
It _may_ be possible to use signals and setjmp/longjmp to reliably
tell a thread to terminate. Honestly, I've never investigated it and
I don't know. I've always done as you suggested above and used
something like a pipe to wake one thread in select from another
thread. For other blocking situations, like a CFRunLoop, there are
almost certainly corresponding ways to unblock a thread.
Ken
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.