Re: doco scm_remember_upto_1

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

Rob Browning <rlb@defaultvalue.org> writes:

> Hmm.  So what level of preemption are we planning to support, or
> rather for what kind of preemption should we be coding defensively?

Well, the situation in CVS HEAD right now is this

   Multiple threads can use Guile concurrently but must follow some
   rules.  A thread can either be in 'Guile mode' or not.

    - When it is not in Guile mode it can not make any calls to
      libguile functions (other than those that explicitely allow
      this)

    - When it is in Guile mode, it can use libguile functions but it
      must cooperate with all other threads that are in Guile mode.
      This means that it must call libguile functions (that do
      consing?)  'regularily' since the global GC can only run from
      within such a function.  When long computations are to be done
      that don't require calls into libguile, either drop out of Guile
      mode or call SCM_TICK at reasonable intervals.

    - Local variables that are created while not being in Guile mode
      are not scanned by the GC.  However, local variables that are
      created while being in Guile mode are continued to being scanned
      also when the thread leaves Guile mode.  Local SCM variables
      that have been created in Guile mode must not be modified while
      being in non-Guile mode.

      That is, you can imagine the stack of a thread to be partitioned
      into alternating Guile mode and non-Guile mode segements.  Only
      SCM references in the Guile segments are being found and they
      must remain constant.  (Requiring them to remain constant is no
      big constraint: threads shouldnot be manipulating SCM objects
      anyway when not being in Guile mode.)

    - When being in Guile mode, all the strange control flow things
      can happen, like exceptions, continuations, asyncs, etc.  Be
      prepared.  This can not happen in non-Guile mode.


I think this is reasonable and it is not necessary to make the GC more
preemptive and then remove the SCM_TICK requirement.  Such a SCM_TICK
is good for asyncs and amybe other things.  When a thread doesn't want
this, it should drop out of Guile mode.

(There are no functions for entering/leaving Guile mode yet...)

So the take-home point is probably that one should deal with whole SCM
objects whenever possible.  When peeking into smobs, care must be
taken, but not on a instruction-by-instruction level, but only from
libguile-function to libguile-function.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel