https://d.puremagic.com/issues/show_bug.cgi?id=12090
Sean Kelly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Sean Kelly <[email protected]> 2014-02-06 10:46:39 PST --- I think something like the following will work: interface Scheduler { void start(void delegate() op); void spawn(void delegate() op); void yield(); @property ref ThreadInfo thisInfo(); Condition newCondition(Mutex m); } When using a scheduler, main() should do any initial setup that it wants and then call scheduler.start(), which will effectively spawn the supplied delegate as a thread and then begin dispatching. The remaining functions are all used by the std.concurrency implementation. spawn() does the work of actually creating new threads, yield() will yield execution of the current fiber (or optionally, thread) so that multiprocessing can occur, and newCondition constructs a Condition object used by send() and receive() to indicate that a message has arrived, block waiting for a new message, etc. Finally, ThreadInfo is needed so that the thread-local statics currently in std.concurrency can be made local to the "thread" currently executing. If thisInfo is called by a thread or fiber not spawned by std.concurrency, it can return a thread-local copy instead. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
