Re: [Caml-list] How does the Thread module work with the Gc?

[Mark Shinwell <mshinwell@janestreet.com>]

On 17 April 2014 09:52, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> How does ocaml switch threads when a signal occurs? What if a thread
> never enters a blocking section? Isn't there some other point where
> tasks can be switched other than enter/leave_blocking_section?
>
> I looked at the implementation for signals and they seem to set the
> allocation limit for the thread to 0 so the next allocation will
> trigger a Gc run. But how does that lead to a thread switch? What am I
> missing here?

Gah, this is a complicated part of the world.

It works as follows when there is no explicit call to release the
OCaml lock.  The ticker thread records a "preemption signal" and sets
the minor heap limit such that the next minor allocation goes to
[caml_garbage_collection].  At this point, pending signals are
processed; and then here is the piece I think you've missed: the
systhreads library has already registered a handler on that signal
(see otherlibs/systhreads/thread.ml) and that handler will cause
[Thread.yield] to be called.  This in turn calls the "yield" operation
in st_posix.h.  On Linux this does nothing; see the comment.  However,
that call (see otherlibs/systhreads/st_stubs.c) is also wrapped in an
enter/leave blocking section, which causes the mutex to be dropped.
At this time, if the stars align and the operating system scheduler is
willing, a thread switch may occur.  There are no guarantees about
fairness made in the runtime at this point (see Xavier's comment on
mantis 5373), so you may in fact find that sometimes a thread does not
yield.  (Also, code that never allocates will not yield unless it
explicitly drops the lock for some other reason.)

Mark