Module Async_unix__.In_thread
module Priority : module type of Core.Linux_ext.Priority with type Priority.t = Core.Linux_ext.Priority.t
module Helper_thread : sig ... end
val pipe_of_squeue : 'a Squeue.t -> 'a Async_kernel.Pipe.Reader.t
pipe_of_squeue squeue
returns a pipep
and consumes the contentssqueue
, placing them inp
. It repeatedly grabs everything fromsqueue
, places it inp
, and then waits for pushback onp
.
val run : ?priority:Priority.t -> ?thread:Helper_thread.t -> ?when_finished:[ `Take_the_async_lock | `Notify_the_scheduler | `Best ] -> ?name:string -> (unit -> 'a) -> 'a Async_kernel.Deferred.t
run ?priority ?thread ?name f
runsf ()
in a separate thread outside Async and returns the result as a Deferred in the Async world. Iff ()
raises an exception (asynchronously, since it is another thread) then that exception will be raised to the monitor that calledrun
.WARNING: Async code MUST NOT be used from within
f
. By Async code we mean pretty-much all functions of libraries making use of Async. Only a few functions of the Async library can be called insideIn_thread.run
. These are explicitly marked as such, using the phrase "thread-safe".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 torun
.If
priority
is supplied, the priority of the thread in the linux scheduler will be set topriority
for the duration off ()
, provided the thread is allowed to do so (seeman setpriority
).If you call
run
several times with the same helper thread, thef ()
calls will run in sequence, in the order in which they are supplied torun
. Eachf ()
will complete (return or raise) before anotherf ()
starts.For example, if you do:
let () = run ~thread f1; run ~thread f2; run ~thread f3;
Then the thread will run
f1 ()
to completion, thenf2 ()
to completion, thenf3 ()
to completion.If
name
is supplied, the name of the thread will be set to it for the duration of the execution off ()
.when_finished
describes how the helper thread behaves oncef ()
has completed:- with
`Take_the_lock
it takes the Async lock and runs a cycle immediately - with
`Notify_the_scheduler
it just notifies the scheduler that the result is ready - with
`Best
it tries to take the lock and run a cycle, but will fallback to`Notify_the_scheduler
method if the Async lock is already held by someone else or the thread is considered unsuitable for running async jobs (e.g. ifthread_pool_cpu_affinity
is used). The default is`Best
, and one shouldn't need to change it -- it is useful only for unit testing.
- with
val syscall : name:string -> (unit -> 'a) -> ('a, exn) Core.Result.t Async_kernel.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, thef
supplied tosyscall
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_kernel.Deferred.t