Re: [Dclib-devel] non blocking patch

[Davis K. <dav...@us...>]

Yeah, I think you are right about the non-blocking reading.

Right now the only way to implement a timeout on a read operation is to use
the dlib::timeout class which is sort of a heavyweight solution.  So having
non-blocking reading seems like it would be a nice alternative.

What do you usually do when you aren't blocking on a call to read?  You have
to be blocking on a call to something else right? sleep() maybe?  Either
that or you are spinning in a loop and killing CPU time.

Cheers,
Davis

On Sat, May 23, 2009 at 2:21 AM, Miguel Grinberg <mig...@ve...>wrote:

> Hi Davis,
>
> I guess for the write side this change is more of a "ready_to_send"
> function. A non-blocking operation cannot be guaranteed, the only thing you
> can ensure is that at least part of your data buffer will get through right
> away.
>
> I'm only using the non-blocking read function right now, that one doesn't
> seem to have any side effects, it seems to me that for read with the use of
> select you can achieve true non-blocking behavior.
>
> In my experience non-blocking writing isn't all that common anyway, I
> normally use non-blocking I/O to prevent my application from blocking while
> waiting for the other end to send data, but when I'm the one sending I don't
> mind blocking.
>
> Thanks for your email.
>
> Miguel
>
> Davis King wrote:
>
>> I have been testing out this patch for a while (on windows and linux) and
>> trying to think if there are any funny corner cases.  I also spent a lot of
>> time a few years ago trying to work something like this into the connection
>> object and ended up giving up but I forgot why until just now.
>> Anyway, I found a problem related to sending data via send().  The problem
>> is that send() will block, even if select() says it won't, if you give it a
>> buffer larger than a certain value (the value depends on your platform and
>> isn't at all portable).  Linux allows you to set the MSG_DONTWAIT flag which
>> fixes the issue but MSG_DONTWAIT isn't a POSIX thing and so isn't portable
>> to other platforms.
>> See http://www.opengroup.org/onlinepubs/009695399/functions/send.html for
>> example.
>>
>> I think the only safe way to get this to work is to create the socket in
>> non-blocking mode to begin with.  Then we don't have to worry about
>> functions blocking when hidden buffer size limits are hit.  So I think that
>> would mean making a new object that explicitly represented a non-blocking
>> socket.
>> I'm not in any dire need for non-blocking sockets so I probably won't be
>> implementing this any time soon.
>> You might also want to check out the asio library (
>> http://think-async.com/Asio/).  It has a whole lot of support for varous
>> kinds of networking modes.  It is also, in all probability, the networking
>> library that will eventually make it into C++ standard library.  So it might
>> be worth learning just for that reason :)
>>
>> Cheers,
>> Davis
>>
>> On Fri, Apr 17, 2009 at 7:35 PM, miguelg50 <mig...@ve...<mailto:
>> mig...@ve...>> wrote:
>>
>>    Davis,
>>
>>    Attached is the patch for the non-blocking socket changes I've
>>    made. I hope
>>    it is useful.
>>
>>    Miguel
>>
>>
>>
>
>