> I guess me question is: what's the pathological IOCP case that's
"unexpected"?
The difference is that on unix a call to alloc_cb() is always immediately
followed by a call to read_cb(); no other callbacks are made in between.
On windows the event loop may do other things between alloc_cb() and
read_cb(), including processing data incoming on different handles, and
waiting for data to actually arrive (so there could be a pause between
alloc_cb and read_cb). That means that while on windows there may be
interleaving between these calls related to different handles, while on
unix there never is.
Note that the code paths that would trigger this on windows are currently
disabled for TCP handles (so TCP essentially behaves exactly the same for
windows and unix in this area), but the interleaving behavior may be seen
for other handle types.
- Bert
On Wednesday, June 4, 2014 9:52:03 AM UTC+2, Nicolas Hillegeer wrote:
>
> That's comforting (and simplifies my code, of course). But then what's
> different from IOCP (completion based) to UNIX-like systems? I think the
>
>
>
> alloc_cb(handle1); alloc_cb(handle2); read_cb(handle1); read_cb(handle2);
>
>
>
> case can equally well happen under UNIX, no? I mean, when you have many
> sockets sending you data, it seems to me that this should be able to
> happen. Not that it's relevant to my use-case as I only have one read
> handle. But it might be good to know for the future (I'll be using more
> handles).
>
>
>
> I guess me question is: what's the pathological IOCP case that's
> "unexpected"?
>
>
>
> Thanks for the answers, and kind regards!
>
>
> (I really hope this ends up on the mailing list this time, I'm just
> pressing the double-arrow icon, what should I press instead?)
>
> Am Dienstag, 3. Juni 2014 18:13:33 UTC+2 schrieb Bert Belder:
>>
>> > > From browsing the internet I got the impression that this sequence of
>> events
>> > > is possible:
>> > >
>> > > alloc_cb();
>> > > alloc_cb();
>> > > read_cb();
>> > > read_cb();
>>
>> That's possible although it would be for different handles.
>>
>> E.g. this could happen:
>>
>> > > alloc_cb(handle1);
>> > > alloc_cb(handle2);
>> > > read_cb(handle1);
>> > > read_cb(handle2);
>>
>> But this isn't:
>>
>> > > alloc_cb(handle1);
>> > > alloc_cb(handle1);
>> > > read_cb(handle1);
>> > > read_cb(handle1);
>>
>> - Bert
>>
>> > -----Original Message-----
>> > From: [email protected] [mailto:[email protected]] On Behalf
>> > Of Iñaki Baz Castillo
>> > Sent: Tuesday, June 03, 2014 5:46 PM
>> > To: [email protected]
>> > Subject: Re: [libuv] interleaved alloc_cb/read_cb, is the libuv test
>> wrong or did I
>> > misunderstand?
>> >
>> > 2014-06-03 17:42 GMT+02:00 Nicolas Hillegeer <[email protected]>:
>> > > From browsing the internet I got the impression that this sequence of
>> events
>> > > is possible:
>> > >
>> > > alloc_cb();
>> > > alloc_cb();
>> > > read_cb();
>> > > read_cb();
>> >
>> > Never seen that under Linux and OSX when using libuv TCP and PIPE
>> handles.
>> >
>> >
>> > --
>> > Iñaki Baz Castillo
>> > <[email protected]>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "libuv" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email
>> > to [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/libuv.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
