[Caml-list] Inter-thread exceptions

[Caml-list] Inter-thread exceptions

[Lauri Alanko]

Hello.

How big a task would it be to implement asynchronous inter-thread
exceptions? In practice the feature would amount to a function:

val raise_to : exn -> Thread.t -> unit

This would be most handy for implementing eg. timeouts: just make a thread
that sleeps and raises an exception in the other thread when the time is
spent.

The GHC folks and John Reppy have done some work on spelling out the
semantics of asynchronous exceptions in Haskell. Could this be used as a
base for a similar system in a strict and impure setting like ocaml? What
would be the main difficulties, both theoretically and implementation-wise?


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Sven LUTHER]

On Tue, Sep 03, 2002 at 04:48:51PM +0300, Lauri Alanko wrote:
> Hello.
> 
> How big a task would it be to implement asynchronous inter-thread
> exceptions? In practice the feature would amount to a function:
> 
> val raise_to : exn -> Thread.t -> unit
> 
> This would be most handy for implementing eg. timeouts: just make a thread
> that sleeps and raises an exception in the other thread when the time is
> spent.
> 
> The GHC folks and John Reppy have done some work on spelling out the
> semantics of asynchronous exceptions in Haskell. Could this be used as a
> base for a similar system in a strict and impure setting like ocaml? What
> would be the main difficulties, both theoretically and implementation-wise?

BTW, also it would be nice to have a (working) way to kill a thread.
There is kill, but it does not seem to be implemented.

Well, what i really want to do is to have a thread running a GUI, and
have some events which will launch another thread doing some
calculation, which may take a long time (or even tnot finish).
So i thought having a button or something in the GUI handled by the main
thread to kill the launched thread would come in handy, saddly, the kill
function is not implemented.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Florian Douetteau]

On Wed, 4 Sep 2002, Sven LUTHER wrote:
>
> BTW, also it would be nice to have a (working) way to kill a thread.
> There is kill, but it does not seem to be implemented.


thread killing is a nice but dangerous feature...
Most of the time the client thread has to tell its server  when it may
be interrupted and when it may not. So that it is  simpler that  the
client code checks periodically a global variable, and stops when it
becomes true.
Java API used to have a Thread.kill method, but it became deprecated from
the 1.1 version.

--
Florian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Xavier Leroy]

> Hello.
> 
> How big a task would it be to implement asynchronous inter-thread
> exceptions? In practice the feature would amount to a function:
> 
> val raise_to : exn -> Thread.t -> unit
> 
> This would be most handy for implementing eg. timeouts: just make a thread
> that sleeps and raises an exception in the other thread when the time is
> spent.

Yes, this is a reasonable model for thread cancellation -- a lot better
than Thread.kill, because the "victim" thread can catch the exception
and perform cleanup actions like releasing mutexes.  

It's not hard to implement with bytecode-level threads (where Caml
does the scheduling), but there is a major difficulty with system
threads: if the target thread is blocked on a system call such as
network I/O, it is extremely difficult to terminate the system call
prematurely and have the target thread honor the exception immediately.

(Under Unix, signals can allow this to some extent, but the semantics
of signals in POSIX threads prevents directing a signal to a
particular thread.  POSIX thread cancellation could perhaps be abused
to deal with this situation, however.  Under Windows, the situation is
even worse...)

So, the only easily implementable behavior is that the target thread
of a "raise_to" operation can delay the processing of the exception
until it returns from a system call.  But this behavior is nearly
useless...

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

>> How big a task would it be to implement asynchronous inter-thread
>> exceptions? In practice the feature would amount to a function:
>> 
>> val raise_to : exn -> Thread.t -> unit
>> 
>> This would be most handy for implementing eg. timeouts: just make a thread
>> that sleeps and raises an exception in the other thread when the time is
>> spent.
>
> Yes, this is a reasonable model for thread cancellation -- a lot better
> than Thread.kill, because the "victim" thread can catch the exception
> and perform cleanup actions like releasing mutexes.  
>
> It's not hard to implement with bytecode-level threads (where Caml
> does the scheduling), but there is a major difficulty with system
> threads: if the target thread is blocked on a system call such as
> network I/O, it is extremely difficult to terminate the system call
> prematurely and have the target thread honor the exception immediately.

Nethertheless I think it's possible for network I/O, and even portable
enough (should work under pthreads/windows threads). Roughly the idea is
following:

0. Create a global "interrupt" socket.
1. Perform select() before  each blocking syscall, waiting for readability
of "interrupt" socket or the necessary state of "main" socket.
3. If "main" socket was in the necessary state, do the syscall.
4. If "interrupt" socket is readable, determine interrupt to which thread
is requested. If it's other thread, call sched_yield() for pthreads
(nothing under Windows) and return to (1)

Interrupt is performed by sending some predefined data to "interrupt"
socket.

Of course this assumes some overhead, but hopefully not that much. 

- Dmitry Bely


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Xavier Leroy]

> Nethertheless I think it's possible for network I/O, and even portable
> enough (should work under pthreads/windows threads). Roughly the idea is
> following:
> 
> 0. Create a global "interrupt" socket.
> 1. Perform select() before  each blocking syscall, waiting for readability
> of "interrupt" socket or the necessary state of "main" socket.
> 3. If "main" socket was in the necessary state, do the syscall.
> 4. If "interrupt" socket is readable, determine interrupt to which thread
> is requested. If it's other thread, call sched_yield() for pthreads
> (nothing under Windows) and return to (1)

For one thing, not all blocking syscalls can be made non-blocking
using select().  (Think opening a FIFO, for instance.)  Moreover, not
all blocking syscalls are in C code that we control.  (Think
gethostbyname(): it will do network I/O to query the DNS, but in a way
that we don't control.)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Inter-thread exceptions

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

>> Nethertheless I think it's possible for network I/O, and even portable
>> enough (should work under pthreads/windows threads). Roughly the idea is
>> following:
>> 
>> 0. Create a global "interrupt" socket.
>> 1. Perform select() before  each blocking syscall, waiting for readability
>> of "interrupt" socket or the necessary state of "main" socket.
>> 3. If "main" socket was in the necessary state, do the syscall.
>> 4. If "interrupt" socket is readable, determine interrupt to which thread
>> is requested. If it's other thread, call sched_yield() for pthreads
>> (nothing under Windows) and return to (1)
>
> For one thing, not all blocking syscalls can be made non-blocking
> using select().  (Think opening a FIFO, for instance.)  Moreover, not
> all blocking syscalls are in C code that we control.  (Think
> gethostbyname(): it will do network I/O to query the DNS, but in a way
> that we don't control.)

Why not to make "non-blocking" as much C functions as possible using
select() technique and simply wait for the completion otherwise? For the
big class of problems this approach is enough. Another crazy idea --
rewrite Ocaml library using non-blocking (asynchronous) IO functions. All
modern OSes (including Windows) should support them.

- Dmitry Bely


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners