Re: [Dclib-devel] non blocking patch

[Miguel G. <mig...@ve...>]

Well, the problem is not that the call to read blocks, it is that it 
blocks forever. The readable() method I added has a timeout, so with 
that I can control for how long I want to block while waiting for data. 
It is a much cleaner way than using dlib::timeout, which if I understand 
it correctly would close the connection when the timeout expires.

Miguel

Davis King wrote:
> 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... <mailto: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...>
>         <mailto: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
>
>
>
>
>