[Issue 12090] New: Make std.concurrency compatible with fibers as threads

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=12090

           Summary: Make std.concurrency compatible with fibers as threads
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody at puremagic.com
        ReportedBy: sean at invisibleduck.org


--- Comment #0 from Sean Kelly <sean at invisibleduck.org> 2014-02-06 10:35:13 PST ---
In order to scale std.concurrency past a small number of threads, some support
must be added for spawning fibers.  Also, std.concurrency should be made
compatible with third-party libraries, like vibe.d, that use fibers as a core
facet of their design.

I had been delaying this project because I felt that any changes to what is
considered a "thread" should support the default thread-local storage model
implicitly.  However, this was based on the idea that any change would be to
the implementation only, and so the user would not necessarily have any
indication that they'd spawned a fiber instead of a kernel thread.

Upon further reflection, I think this approach is not the correct one, and as
per the design of Druntime, the user should be given the choice of how
multiprocessing will occur.  Then the choice to use fibers instead of threads,
for example, can be made by the user at design time with the knowledge that
their code doesn't use thread-local statics in an incompatible manner.  This
serves to decouple the thread-local storage issue from multiprocessing in
general and lets us move forward on std.concurrency without being blocked by a
technical obstacle in Druntime.

So std.concurrency should be adapted so that the multiprocessing model can be
configured, at process startup, by plugging in a Scheduler which handles the
details of spawning threads, yielding instead of blocking on a wait when a
message queue is empty, and so on.  By default, if no Scheduler is supplied,
std.concurrency should work just as it always has.  This will save any memory
allocations or performance penalties in the typical case.  Also, the design
should be such that any allocations are minimized as much as possible.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------