From: Seth Kurtzberg <seth@...>
Date: 2003-03-03T16:32:17+09:00
Subject: Re: More on blocking...

Ah, OK, now I begin to see also.

Does this also apply to the recv() call?

I've written some code that does the reading in a separate thread, and writes 
the data to a pipe.  The original thread then reads from the pipe.  The 
reason this helps is that I store the available data length in a class 
variable protected by a mutex.  Also that let's me do buffered reads on the 
data stream, reading from the pipe instead of the socket.

Clearly, though, this doesn't help if recv() also blocks.  Do you think that 
it will?

On Monday 03 March 2003 12:04 am, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "More on blocking..."
>
>     on 03/03/03, Seth Kurtzberg <seth@cql.com> writes:
> |I have a situation where I call select, which shows that there is data
> |available on a socket.  I then do a read() call on this socket.  The read
> |then takes 10 to 15 seconds to complete.  This occurs only occasionally,
> | but it is repeatable, so I'm hopeful that I will be able to get a test
> | case working.
> |
> |My question is, what is the definition of "block", in this context?  In
> | fact, this particular call does not block, it eventually completes.  What
> | I don't understand is what makes it wait for some particular number of
> | bytes before returning.  In the case I've gotten details on, there are
> | 568 bytes read. This is smaller than the MTU and so arrives as one packet
> | (confirmed with tcpdump).
> |
> |It is also possible that there is a threading issue.  However, I have
> | trace statements in all threads, and I don't see any activity in any
> | other thread during this 10-15 second pause.
>
> Finally, I got the clue, I think.  You're mixing non-blocking IO with
> threads, aren't you?  Reading thread "blocks" until the file
> descriptor become ready (detected by select(2)).  It's not documented
> in the Linux man page for select(2), but I think select(2) would wait
> for data even if the fd is non-blocking.
>
> There's no way to tell the thread scheduler to the fd is non-blocking.
> What shall we do?
>
> 							matz.

-- 
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com