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

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.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/