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

2015-02-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

--- Comment #9 from github-bugzi...@puremagic.com ---
Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/b956f687bfc1de41993cb3950b38214e55369c2d
Merge pull request #1910 from complexmath/addConcurrencyScheduler

--


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

2015-09-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

Mathias LANG  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||pro.mathias.l...@gmail.com
 Resolution|--- |FIXED

--- Comment #10 from Mathias LANG  ---
This was fixed in 2.067 but since the title of the P.R. didn't include "Fix",
bugzilla didn't pick it up.
Note: It's not showing up in the changelog as a result.

--


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

2014-02-06 Thread d-bugmail
https://d.puremagic.com/issues/show_bug.cgi?id=12090


Sean Kelly  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED


--- Comment #1 from Sean Kelly  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: ---


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

2014-02-09 Thread d-bugmail
https://d.puremagic.com/issues/show_bug.cgi?id=12090


Jakob Ovrum  changed:

   What|Removed |Added

 CC||jakobov...@gmail.com


--- Comment #2 from Jakob Ovrum  2014-02-09 07:15:04 PST 
---
(In reply to comment #1)
> 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.

It has been suggested that std.concurrency should also be able to support IPC
(most importantly by Andrei in the module's documentation). The proposed
Scheduler interface seems close to supporting that for fork()-based code (which
of course isn't an option for non-POSIX systems), but do you have any thoughts
on this?

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


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

2014-02-11 Thread d-bugmail
https://d.puremagic.com/issues/show_bug.cgi?id=12090


yebblies  changed:

   What|Removed |Added

 CC||yebbl...@gmail.com


--- Comment #3 from yebblies  2014-02-11 22:36:03 EST ---
(In reply to comment #2)
> 
> It has been suggested that std.concurrency should also be able to support IPC
> (most importantly by Andrei in the module's documentation). The proposed
> Scheduler interface seems close to supporting that for fork()-based code 
> (which
> of course isn't an option for non-POSIX systems), but do you have any thoughts
> on this?

IPC depends on serialization, which we don't have yet in phobos.

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


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

2014-02-13 Thread d-bugmail
https://d.puremagic.com/issues/show_bug.cgi?id=12090



--- Comment #4 from Jakob Ovrum  2014-02-13 07:45:00 PST 
---
(In reply to comment #3)
> (In reply to comment #2)
> > 
> > It has been suggested that std.concurrency should also be able to support 
> > IPC
> > (most importantly by Andrei in the module's documentation). The proposed
> > Scheduler interface seems close to supporting that for fork()-based code 
> > (which
> > of course isn't an option for non-POSIX systems), but do you have any 
> > thoughts
> > on this?
> 
> IPC depends on serialization, which we don't have yet in phobos.

Well, the fact remains that the Scheduler interface may not be forward
compatible with IPC. I think it's worth pointing out.

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


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

2014-04-27 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

Brad Anderson  changed:

   What|Removed |Added

 CC||e...@gnuk.net

--- Comment #5 from Brad Anderson  ---
The pull request looks nice. How hard do you think it'd be to add an M:N
scheduler to the mix?

--


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

2014-05-01 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

--- Comment #6 from Sean Kelly  ---
Not hard.  The existing schedules should serve as a decent basis for the work.

--


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

2014-07-09 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #7 from Walter Bright  ---
https://github.com/D-Programming-Language/phobos/pull/1910

--


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

2014-10-22 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12090

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/b956f687bfc1de41993cb3950b38214e55369c2d
Merge pull request #1910 from complexmath/addConcurrencyScheduler

Issue 12090 - Make std.concurrency compatible with fibers as threads

--