http://d.puremagic.com/issues/show_bug.cgi?id=4365

           Summary: Shared receive for all waitable objects
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: pjdeets2@gmail.com


--- Comment #0 from Phil Deets <pjdeets2@gmail.com> 2010-06-22 03:04:28 PDT ---
I would like the ability to have the same thread block on a socket and block on cross-thread messages at the same time. Currently, the receive function in std.concurrency and the receive function in std.socket are not tied together at all, so I don't think this is possible without modification to the standard library.

Thanks,
Phil Deets

Disclaimer: I work for Microsoft, but I am not representing them in any way by this post.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4365


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |thecybershadow@gmail.com
         Resolution|                            |WONTFIX


--- Comment #1 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-08-23 22:15:02 PDT ---
Heh, the coveted One True Event Loop... unless you can get select() and whatever synchronization primitives various platforms use to play together, this isn't going to happen. Since you've decided to mention that you work for Microsoft, let's look at Windows specifically - I don't see a WSASelectAndWaitForMultipleObjects function anywhere. You'll just need to put your event loops in different threads and make one pass its events to whichever you pick as your "main" one (or alternatively, use a lock on the global state and process events in the same thread).

If anyone has any realistic ideas, feel free to reopen.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4365



--- Comment #2 from Phil Deets <pjdeets2@gmail.com> 2011-08-28 05:12:28 PDT ---
I'm not an expert in Windows sockets, but I think this might actually be doable in Windows. The select function does synchronous IO; so it isn't possible with that, but I think if you use other functions (WSAEventSelect looks promising), you can associate the wait with a handle that you can use with WaitForMultipleObjects. I won't reopen the bug though as this isn't very important to me anymore.

As for the disclaimer, I was newer to the job then and was perhaps a bit overly cautious about how I handled Internet communications.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4365



--- Comment #3 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-08-28 12:20:40 PDT ---
Good point with WSAEventSelect. Still, it'd need some major refactoring, special-casing Windows, and we still don't know how to do this on POSIX (getting pthreads and select to work together, I guess). Web search results on the topic aren't very inspiring: http://www.google.com/search?q=pthreads+select

Creating two threads with each processing its type of events still seems the way to go.

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