[MLton-devel] cvs commit: Callbacks

[Matthew Fluet]

> > > +			     (new (fn () =>
> > > +				   let val (b,f) = !r in
> > > +				     if b then atomicEnd () else ()
> > > +				     ; f ()
> > > +				     ; Prim.setSaved t
> > > +				     ; if b then atomicBegin () else ()
> > > +				     ; Prim.returnToC ()
> > > +				   end)))
> >
> > My question is whether the (optional) atomicBegin should occur before
> > Prim.setSaved t?  Under the Callback mechanism, the atomicBegin is
> > performed by the handler (i.e., in the  f ()  above), so it occurs before
> > the Prim.setSaved.  I'm just never quite sure when to do atomic operations
> > around thread manipulations.
>
> The point in this case is that setSaved stores in the gcState and
> returnToC expects to see the value that was stored.  So, we must use a
> critical section to avoid a thread switch between the two.  As it
> stands above, I don't see any point to the conditional atomicBegin ().
> It looks like it should be before the setSaved.

O.k., then I think there was a bug in the setCallFromCHandler code before
the check-in.  Before the changes I made, there was no atomicBegin at all
and no canHandle-- in MLton_callFromC.  In practice, I'm almost certain
that there is no opportunity to switch threads between Prim.setSaved and
Prim.returnToC (there is no allocation or loop for a limit check, and that
only applies when there are interrupts).  I don't know what our "idealized
model" is to know whether or not "in theory" we might switch threads.

In any event, I'll make the proposed changes.



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel