[MLton-devel] cvs commit: Callbacks

[Stephen Weeks]

> > +			     (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.

> If it does make sense to move the atomicBegin before the Prim.setSaved,
> then it's probably just as well to drop the boolean and have
> MLton.FFI.handleCallFromC compose the function with the atomicBegin/End.

OK, as long as the comment for setCallFromCHandler says that its
argument should expect to start in a critical section and should
return in a critical section.  Boy it sure would be nice to have some
help from the type system here.  I wonder if the haskell people use
monads for critical sections.



-------------------------------------------------------
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