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_first16:string -> (unit -> 'a) -> 'a Async_core.Deferred.t
run ?thread ?name_first16 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_first16
is supplied, the name of the thread will be set to it for the
duration of the execution of f ()
.
val syscall : (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 : (unit -> 'a) -> 'a Async_core.Deferred.t