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

I'm  confused  about why something in MLton is safe from race conditions
(coming  from  Unix  signals).   The  C  functions  Real32_gdtoa()   and
Real64_gdtoa()  return  a  C  string.  Since the caller doesn't free the
result, it must point to some memory  which  is  re-used  by  successive
calls.   That's  fine  most of the time because the ML code in the basis
library copies the data to a MLton string pretty much right away.

What I am worried about what stops a signal being serviced (by ML  code)
after  Real*_gdtoa()  has  returned and before the result is copied.  If
that signal handler  converts  a  real  to  a  string,  then  this  will
overwrite  the memory and the original caller will get the wrong result.
The same thing, it seems to  me,  could  happen  from  a  GC  running  a
finalizer.

This  is  exactly  the kind of problem that was solved before by the One
structure (in basis-library/util/one.sml),  but  that  won't  work  here
because  the space is allocated and reused in C code.  It seems like one
would have to wrap the combination of calling  Real*_gdtoa()  and  using
the result in a critical region.

Am I missing something?

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