Re: [MLton] MLton race condition (similar to what was solved by structure One)?

Matthew Fluet <[email protected]> Sun, 12 Apr 2015 14:19:48 -0400
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAMrhFL7KUR633QJt_KcM7joFtf=axcdG0KmEbvqq5eF0k0vM7g@mail.gmail.com>
On Tue, Mar 31, 2015 at 2:55 AM, Henry Cejtin <[email protected]> wrote:
> After  a  few  more hours I see exactly how what is happening in my test
> happens: The signal arrives as the main thread is calling  Real64_gdtoa.
> This  causes the MLton runtime (C code) to set a flag indicating that an
> ML handler has to run, but the main thread is in C code, so nothing else
> is  done.   Then  the  Real64_gdtoa  (called  from  the  main thread) is
> continued.  As it returns to ML code (inside of Real.toString), the flag
> set  is  observed  and the handler is run.  This calls Real64_gdtoa with
> the value 9.0, and finishes off the Real.toString,  correctly  returning
> "9".   Then  we  return to the main thread.  It is in Real.toString, but
> now the string returned by its call to Real64_gdtoa still  contains  "9"
> instead of the "1" put there before.
>
> This  definitely  is  the  bug  I  was  worried  about.   The  fact that
> Real64_gdtoa is not thread safe means  that  there  has  something  like
> atomicBegin  and  atomicEnd  just  before  it  is called until after its
> (pointing to the malloc heap) is done being used.

I agree completely with the whole analysis.  The ideal solution, and
the one that we use for a number of other runtime functions where the
C-side wants to allocate a result, would be to allocate the storage in
ML and send the array over to C to be filled.  Unfortunately, the
gdtoa functions don't support that use case.  I think that the issue
is that there isn't an easy way to pre-determine the number of
characters needed to hold the result of a correctly-rounded float to
string conversion; essentially, one only discovers the size during
conversion.  Although, it would not be unreasonable to use the
structure One approach to keep storage for the largest possible float
conversion.  We could then do the copy from the gdtoa buffer to the
ML-allocated buffer in the Real{64,32}_gdtoa wrapper, returning the
number of characters that were copied (so that the ML-side could then
copy from the mutable array to an immutable string).

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF