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