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

On Sun, Apr 12, 2015 at 4:22 PM, Henry Cejtin <[email protected]> wrote:
> It  looks  like all the functions already rather quickly copy the result
> to something else (a ML  string  or  else  an  IEEEReal.decimal_approx).
> Personally  I  don't  like  the  decimal_approx type.  The fact that the
> digits are stored as an int list is very  expensive.   It  requires  one
> allocation  per  digit and a translation from ASCII to numbers between 0
> and 9.

Agreed that decimal_approx is not a very efficient representation for
the information that it carries.

> Any way, should I just insert calls to atomicBegin and  atomicEnd  (from
> MLton.Thread)?   (I am assuming that that would block any signal handler
> from running, correct?)

Yes, atomicBegin/End would prevent switching to the signal handler
thread.  That would probably be the simplest edit, though as you note,
some of the uses of Real_gdtoa do not immediately consume the C string
(or, at least, the loop that consumes the C string is not always the
same ML function that calls Real_gdtoa).

> I  think  that  I  have  permission  to  commit
> changes on the Git repository.

I don't think that I had a GitHub account for you when I created the
MLton organization/repository.  In any case, I've avoided pushing
directly to the MLton/mton repository; rather, I've used GitHub pull
requests to mediate.

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