[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] thread-wait-for-i/o! and thread-terminate!
From: |
Chris Vine |
Subject: |
Re: [Chicken-users] thread-wait-for-i/o! and thread-terminate! |
Date: |
Wed, 21 Jan 2015 11:52:31 +0000 |
Jörg F. Wittenberger wrote:
> John is right about the general case. There are however circumstances
> when you just want to abort some operation. If you know what you do,
> external abort is sometimes ok. Most of the time however I'd
> recommend to use thread-signal! to allow the terminated thread
> receive an exception and abort cleanly.
>
> Chicken _itself_ however should not end up in an inconsistent state
> because of thread-terminate!.
As I wrote in my original posting, I know of the dangers, and my _own_
code is termination safe. The i/o thread which waits on
thread-wait-for-i/o! has a termination mutex, which must always be
acquired by another thread before it calls thread-terminate! on the i/o
thread. The i/o thread always holds that mutex (to block all
termination events) except when in thread-wait-for-i/o!, which it loops
on, handling i/o events asynchronously as they arrive. So
thread-terminate! can only be called on it when it is in the
thread-wait-for-i/o! procedure.
So my question was, as you say, whether chicken _itself_ could end up
in an inconsistent state because of thread-terminate!
The other option which I had in mind (if chicken _itself_ is termination
unsafe) was to cause thread-wait-for-i/o! to unblock by closing the
file descriptor. However, the program logic works better if the
descriptor is not closed (it might be needed again). Using
thread-signal! had not occurred to me, partly because it is not in
SRFI-18 and partly because the chicken documentation seems impenetrable
on what it does: "This will cause THREAD to signal the condition X once
it is scheduled for execution. After signalling the condition, the
thread continues with its normal execution." It looks from what you
say as if it causes a resumable exception in the receiver thread which
can be caught by it with with-exception-handler, which would work OK for
my purposes. (I thought SRFI-18 exceptions were non-continuable?).
However, if chicken itself is termination safe then I think that I can
stick with my current approach.
Chris