2019-12-16 11:09 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000125mercuryBugpublic2014-07-10 17:28
Reporterwangp 
Assigned Towangp 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000125: thread.spawn should spawn OS thread in low-level C grades
DescriptionIn low-level C grades, thread.spawn creates a new context but not a OS thread. The idea was to multiplex contexts onto OS threads, but this isn't implemented and won't work unless you use non-blocking I/O everywhere, including in user-defined foreign procs. We should just create a new OS thread, as we do in high-level C grades.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000238

pbone (administrator)

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 (developer)

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 (administrator)

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 (developer)

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 (developer)

Added thread.spawn_native.
+Notes

-Issue History
Date Modified Username Field Change
2010-01-06 15:40 wangp New Issue
2010-01-06 16:02 pbone Note Added: 0000238
2010-01-06 16:26 wangp Note Added: 0000239
2010-01-06 16:44 pbone Note Added: 0000240
2010-01-06 17:16 wangp Note Added: 0000241
2014-07-10 17:28 wangp Note Added: 0000738
2014-07-10 17:28 wangp Status new => resolved
2014-07-10 17:28 wangp Resolution open => fixed
2014-07-10 17:28 wangp Assigned To => wangp
+Issue History