From: matz@... (Yukihiro Matsumoto)
Date: 2003-03-03T16:04:12+09:00
Subject: Re: More on blocking...

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.