module Scheduler: Scheduler
val go : ?raise_unhandled_exn:bool -> unit -> Core.Std.never_returns
go ?raise_unhandled_exn ()
passes control to Async, at which point Async starts
running handlers, one by one without interruption, until there are no more handlers to
run. When Async is out of handlers it blocks until the outside world schedules more
of them. Because of this, Async programs do not exit until shutdown
is called.
go ()
calls handle_signal Sys.sigpipe
, which causes the SIGPIPE signal to be
ignored. Low-level syscalls (e.g. write) still raise EPIPE.
If any async job raises an unhandled exception that is not handled by any monitor,
async execution ceases. Then, by default, async pretty prints the exception, and
exits with status 1. If you don't want this, pass ~raise_unhandled_exn:true
, which
will cause the unhandled exception to be raised to the caller of go ()
.
val go_main : ?raise_unhandled_exn:bool ->
main:(unit -> unit) -> unit -> Core.Std.never_returns
go_main
is like go
, except that one supplies a main
function that will be run to
initialize the async computation, and that go_main
will fail if any async has been
used prior to go_main
being called.type'a
with_options =?work_group:Work_group.t ->
?monitor:Import.Monitor.t -> ?priority:Import.Priority.t -> 'a
val within_context : Import.Execution_context.t -> (unit -> 'a) -> ('a, unit) Core.Std.Result.t
within_context context f
runs f ()
right now with the specified execution
context. If f
raises, then the exception is sent to the monitor of context
, and
Error ()
is returned.val within' : ((unit -> 'a Import.Deferred.t) -> 'a Import.Deferred.t)
with_options
within' f ~work_group ~monitor ~priority
runs f ()
right now, with the specified
block group, monitor, and priority set as specified. They will be reset to their
original values when f
returns. If f
raises, then the result of within'
will
never become determined, but the exception will end up in the specified monitor.val within : ((unit -> unit) -> unit) with_options
within
is like within'
, but doesn't require thunk to return a deferred.val within_v : ((unit -> 'a) -> 'a option) with_options
within_v
is like within
, but allows a value to be returned by f
.val schedule' : ((unit -> 'a Import.Deferred.t) -> 'a Import.Deferred.t)
with_options
within'
, but instead of running thunk right now, adds
it to the async queue to be run with other async jobs.val schedule : ((unit -> unit) -> unit) with_options
val cycle_start : unit -> Core.Std.Time.t
cycle_start ()
returns the result of Time.now ()
called at the beginning of
cycle.val cycle_times : unit -> Core.Std.Time.Span.t Import.Stream.t
cycle_times ()
returns a stream that will have one element for each cycle that Async
runs, with the amount of time that the cycle took (as determined by calls to Time.now
at the beginning and end of the cycle).val report_long_cycle_times : ?cutoff:Core.Std.Time.Span.t -> unit -> unit
report_long_cycle_times ?cutoff ()
sets up something that will print a warning to
stderr whenever there is an async cycle that is too long, as specified by cutoff
,
whose default is 1s.val cycle_count : unit -> int
cycle_count ()
returns the total number of async cycles that have happened.val is_running : unit -> bool
is_running ()
returns true if the scheduler has been started.val set_max_num_jobs_per_priority_per_cycle : int -> unit
set_max_num_jobs_per_priority_per_cycle int
sets the maximum number of jobs that
will be done at each priority within each async cycle. The default is 500
.val is_ready_to_initialize : unit -> bool
val reset_in_forked_process : unit -> unit
reset_in_forked_process
at the
start of execution in the child process. After that, the child can do async stuff and
then start the async scheduler.