Home Original page

Is it just me, or..

Markus Stenberg mstenber at cc.Helsinki.FI
Mon Jul 5 02:44:02 EDT 1999 
"Michael P. Reilly" <Michael.P..Reilly at p98.f112.n480.z2.fidonet.org> writes:
> From: "Michael P. Reilly" <arcege at shore.net>
> Markus Stenberg <mstenber at cc.Helsinki.FI> wrote:
> : Is there a bug in the handling of pipes with the Python? Esp. in
> : non-blocking way.
> : Example:
> :  (r,w)=os.pipe()
> :  r = os.fdopen(r, "r", 0)
> :  w = os.fdopen(w, "w", 16384)
> :  w.write('foobarbaz')
> :  select.select([r],[],[]) # returns r, as it should
> :  r.read(1) # returns 'f'
> :  select.select([r],[],[]) # blocks!
> 
> : Now select _blocks_, despite there being obviously some data that at least
> : should not have been buffered elsewhere. Also, fdopened stuff's reading
> : features are bit annoying, as doing read(bigNumber) results in blocking
> : call, as opposed to recv(bigNumber)'s semantics. Thus instead of pipes
> : (=fast) I am using TCP/UNIX sockets (=slow) but they seem to work better
> : for what I need. Am I missing something really obvious?
> 
> : This is on Linux, if it matters.
> 
> At first glance, I'd say that it is the buffering in the fdopen(w, "w",
> 16384) call.  Put the bufsize to 0 or call the flush method.


Oh, yes, I was flushing it (that example was done by hand out of existing
code that is actually in use). Yet, still no dice. Also, buffer size for
"r"does not matter (0,1,N); behavior is same always. Frustrating. (Oh
well. UNIX sockets work, I suppose)

>   -Arcege

-- 

	Markus Stenberg
More information about the Python-list mailing list