How many std.concurrency receivers?

[Dmitry Olshansky]

On 15-Oct-12 05:58, Sean Kelly wrote:
> On Oct 14, 2012, at 9:59 AM, Dmitry Olshansky <dmitry.olsh at gmail.com> wrote:
>
>> On 14-Oct-12 20:19, Sean Kelly wrote:
>>> On Oct 12, 2012, at 2:29 AM, Russel Winder <russel at winder.org.uk> wrote:
>>>
>>>> On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote:
>>>> […]
>>>>> I'm not clear on what Fibers are.  From Ruby they seem to mean
>>>>> co-routines, and that doesn't have much advantage.  But it also seems as
>>>> […]
>>>>
>>>> I think the emerging consensus is that threads allow for pre-emptive
>>>> scheduling whereas fibres do not. So yes as in Ruby, fibres are
>>>> collaborative co-routines. Stackless Python is similar.
>>>
>>> Yep. If fibers were used in std.concurrency there would basically be an implicit yield in send and receive.
>>
>> Makes me wonder how it will work with blocking I/O and the like. If all of (few of) threads get blocked this way that going to stall all of (thousands of) fibers.
>
> Ideally, IO would be nonblocking with a yield there too, at least if the operation would block.

I'm wondering if it will be possible to (sort of) intercept all common 
I/O calls in 3rd party C libraries. Something like using our own 
"wrapper" on top of C runtime but that leaves BSD sockets and a ton of 
WinAPI/Posix primitives to care about.

-- 
Dmitry Olshansky