module In_thread: In_thread
module Helper_thread:sig
..end
val pipe_of_squeue : 'a Core.Std.Squeue.t -> 'a Async_core.Pipe.Reader.t
pipe_of_squeue squeue
returns a pipe p
and consumes the contents squeue
, placing
them in p
. It repeatedly grabs everything from squeue
, places it in p
, and
then waits for pushback on p
.run
to run_exn
, and add run
returning an
('a, exn) Result.t Deferred.t
.val run : ?thread:Helper_thread.t ->
?name:string -> (unit -> 'a) -> 'a Async_core.Deferred.t
run ?thread ?name f
runs f()
in another thread and returns the result as a
Deferred in the Async world. If f()
raises an exception (asynchronously, since it
is another thread) then that exception will be raised to the monitor that called
run()
.
Async code should not be used from within f
.
If thread
is not supplied, then any thread from the thread pool could be used. If
you need to run routines in a specific thread (as is required by some libraries like
Sqlite), you should create a helper thread and supply it to run
.
If you call run
several times with the same helper thread, the f()
calls will run
in sequence, in the order in which they are supplied to run
. Each f()
will
complete (return or raise) before another f()
starts.
For example, if you call:
run ~thread f1
run ~thread f2
run ~thread f3
Then the thread will run f1 ()
to completion, then f2 ()
to completion, then
f3 ()
to completion.
If name
is supplied, the name of the thread will be set to it for the duration of
the execution of f ()
.
val syscall : name:string ->
(unit -> 'a) -> ('a, exn) Core.Std.Result.t Async_core.Deferred.t
syscall f
runs f, which should be a single system call, and returns the result,
handling the restarting of interrupted system calls. To avoid race conditions, the
f
supplied to syscall
should just make a system call. That way, everything else
is done holding the Async lock.val syscall_exn : name:string -> (unit -> 'a) -> 'a Async_core.Deferred.t