Ok, after glancing at the code, I left the default behavior using
read() because that was the pre-existing behavior, and there's code in
thrift that relies on it. For example, when the framed transport wants
data, it read()'s 4 bytes, then read()'s the number of bytes described
by those first 4 bytes. If Thrift::Socket used readpartial everywhere,
then the framed transport code would break because it expects to block
until the data it asked for is all there.
-Kevin Ballard
On Jun 20, 2008, at 4:38 PM, Kevin Clark wrote:
Figured this discussion might be useful for others, so we'll
continue it here...
19:33 < kevinclark> Eridius_: is there a reason you didn't just swap
Thrift::Socket over to readpartial completely? I
_think_ my
borrow implementation on BufferedTransport relies
on that
(since it asks for more than could be available,
and I
don't want it to blcok, but I don't want it to
necessarily
rely on Socket)
19:34 < kevinclark> Eridius_: I'm finishing up a 3rd try at this
merge, I'd
appreciate it if you'd review before I push. I'm
going to
make a ticket for it.
19:34 < Eridius> send me an email, I can't focus on IRC right now
19:34 < kevinclark> k
19:35 < Eridius> quick comment: readpartial blocks if there's
nothing to read.
read_nonblock doesn't.
19:35 * Eridius idles again
19:35 < kevinclark> but it seems to fallback to read, not
read_nonblock.
--
Kevin Ballard
[EMAIL PROTECTED]
