Open ramLlama opened 7 years ago
There is already an Unsafe
module (basis-library/sml-nj/unsafe.{sig,sml}
), although within the Basis Library implementation (i.e., before we constrain the Array
module to that specified by the Basis Library), you have Array.arrayUninit
available.
Isn't that Unsafe a compatibility structure with SML/NJ Unsafe? What has been mainline MLton's thoughts on where to put MLton-specific unsafe things?
Also, yes, we would use the same Array.arrayUninit that is provided in the basis, not a reimplementation. We just a need a place to put it.
Yes, the exported structure Unsafe
is for compatibility with SML/NJ. We haven't needed to export MLton-specific unsafe things. Within the Basis Library implementation, we simply use *Unsafe
functions within their natural structures. So, it is really a question of whether these operations are meant for export to user programs or just for internal implementation.
MLton.Parallel is currently a "bag of stuff". It's worth organizing this. I'll go section by section
Reorganization
I propose the following:
MLton.Parallel
: containsnumberOfProcessors
,processorNumber
,registerProcessorFunction
, andinitializeProcessors
MLton.Parallel.Atomics
: Contains atomics such as CAS and fetch-and-addMLton.Parallel.Synchronization
: Contains locks. Perhaps should have more substructures such asSpinlock
, etc. (although we only have a spinlock for now)Deprecated
We have a few things in
MLton.Parallel.Deprecated
that have been there a while. We should handle them.My thoughts:
yield
: If no one is using this, let us remove it entirely.lockInit
,takeLock
,releaseLock
: Move this out of Deprecated. Move intoMLton.Parallel.Synchronization
, proposed previouslyUnsafe
arrayUninit
: This aren't parallel-only and shouldn't be inMLton.Parallel.Unsafe
. Perhaps in a newMLton.Unsafe
?arrayCompareAndSwap
,arrayFetchAndAdd
: Should be inMLton.Parallel.Atomics
, proposed previously.Top-level
MLton.Parallel.Atomics
structure, proposed previously. Perhaps, we should even have a higher levelMLton.Atomics
structure. In addition, we should expand this to support all primitive types.