|
Notes |
|
|
(0000238)
|
|
pbone
|
|
2010-01-06 16:02
|
|
This will be non-trivial to implement.
In many recent changes to the runtime we've assumed that engines can only be created at initialization time and that the number of engines running will always be constant. I don't see this going away anytime soon, In particular some optimizations I'd like to make to work stealing rely on this assumption.
GHC handles this differently, when code makes any foreign call the engine that it was using becomes 'freed' while the foreign call is in progress, then the existing engine can pick up other available work. This allows them to do concurrent IO without the programmer having to wrap their head around asynchronous system calls. More performance is probably available by using asynchronous system calls though. This will also be non-trivial for us to implement but it won't harm any assumptions that I (personally) like.
I would like to see our runtime handle asynchronous IO nicely while isolating the C foreign procedure writer from worrying about this. I'd also like to see Mercury and other pure languages use mmap() for reading and writing files more often, hopefully we can worry about buffering less and let the kernel handle this - Manipulating buffers in a pure language is not pretty. Of course this would become difficult when using network sockets as I don't think they support mmap(). |
|
|
|
(0000239)
|
|
wangp
|
|
2010-01-06 16:26
|
|
|
If it comes down to it, could we not distinguish parallel-conjunction-capable engines/threads from the threads created by thread.spawn? Eventually spawned threads should be capable of running code containing parallel conjunctions, but right now one feature is a research project, the other is practical, and the two don't have to meet just yet. It's the last resort, though. |
|
|
|
(0000240)
|
|
pbone
|
|
2010-01-06 16:44
|
|
What should the runtime behavior be when a non parallel conjunction capable engine executes a parallel conjunction?
It sounds like this is just a work around for asynchronous IO, which is the real problem here. Fixing asynchronous IO is the better long-term solution. |
|
|
|
(0000241)
|
|
wangp
|
|
2010-01-06 17:16
|
|
Abort?
Asynchronous IO might be fine when you can get it (I don't know), but outside of the standard library there are a lot of functions that you might want to call which have no asynchronous equivalent. |
|
|
|
(0000738)
|
|
wangp
|
|
2014-07-10 17:28
|
|
|
Added thread.spawn_native. |
|