You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: contains numberOfProcessors, processorNumber, registerProcessorFunction, and initializeProcessors
MLton.Parallel.Atomics: Contains atomics such as CAS and fetch-and-add
MLton.Parallel.Synchronization: Contains locks. Perhaps should have more substructures such as Spinlock, 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 into MLton.Parallel.Synchronization, proposed previously
Unsafe
arrayUninit: This aren't parallel-only and shouldn't be in MLton.Parallel.Unsafe. Perhaps in a new MLton.Unsafe?
arrayCompareAndSwap, arrayFetchAndAdd: Should be in MLton.Parallel.Atomics, proposed previously.
Top-level
The CAS operations should perhaps go into a MLton.Parallel.Atomics structure, proposed previously. Perhaps, we should even have a higher level MLton.Atomics structure. In addition, we should expand this to support all primitive types.
The text was updated successfully, but these errors were encountered:
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.
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.The text was updated successfully, but these errors were encountered: