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