module Tutils:Multithreading utilitiessig..end
val create : ('a -> unit) -> 'a -> string -> Thread.tmain
will notice it.
The main process is expected to run main after having launched
the needed threads: that function will sleep until a thread
raises an exception.val main : unit -> unitval shutdown : unit -> unitexception Exit
val join_all : unit -> unitval running : string -> Thread.t -> booltype priority =
| |
Blocking |
(* | For example a last.fm submission. | *) |
| |
Maybe_blocking |
(* | Request resolutions vary a lot. | *) |
| |
Non_blocking |
(* | Non-blocking tasks like the server. | *) |
val scheduler : priority Duppy.schedulerval need_non_blocking_queue : unit -> unitval wait : Condition.t -> Mutex.t -> (unit -> bool) -> unitf() to become true on condition c.
The mutex m protecting data accessed by f is in the same state before
and after the call.val mutexify : Mutex.t -> ('a -> 'b) -> 'a -> 'bexception Timeout
val wait_for : ?mutex:Mutex.t ->
?log:(string -> unit) ->
[ `Both | `Read | `Write ] -> file_descr -> float -> unitval finalize : k:(unit -> unit) -> (unit -> 'a) -> 'afinalize ~k f calls f and returns it result,
and always executes k, even when f raises an exception.val seems_locked : Mutex.t -> booltrue is always returned:
it always "seems" OK, we don't raise false alarms.
This is meant to be used for assertions.val lazy_cell : (unit -> 'a) -> unit -> 'aval stoppable_thread : ((unit -> bool) * (unit -> unit) -> unit) ->
string -> (unit -> unit) * (unit -> unit)
The thread function receives a should_stop,has_stop pair on startup.
It should regularly poll the should_stop and stop when asked to.
Before stopping it should call has_stopped.
The function returns a kill,wait pair. The first function should be
called to request that the thread stops, and the second to wait
that it has effectively stopped.