http://bugzilla.spamassassin.org/show_bug.cgi?id=4258
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2005-05-04 00:00 -------
OK, after some investigation offline, I've figured this out --
<jmason> I think we have a perl IO issue
<jmason> 5664 perl 1115186325.449041 CALL read(0x8,0x8c77000,0x2000)
<jmason> 5664 perl 1115186325.449053 GIO fd 8 read 12 bytes
<jmason> "B5682
<jmason> I5682
<jmason> "
<jmason> note the two lines in the one read
<jmason> it totally misses the second one...
<jmason> the problem is this
<jmason> 1. parent calls select(), which says "channel N is active"
<jmason> 2. it reads from channel N
<jmason> 3. perl calls read(2) and gets those 2 lines
<jmason> 4. perl returns one of those 2 lines to our code
<jmason> 5. parent later calls select() again, and gets no activity -- although
there is a line that wasn't processed sitting in the stdio buffer
<jmason> we call $socket->getline()
<quinlan> you're not mixing sysread/syswrite/etc. with read/write, etc. ?
<jmason> nope. but perhaps select() doesn't mix with readline()
<jmason> at least not on freebsd ;)
Moving to a new protocol that uses fixed-size buffers instead of variable-length
"lines" fixes the bug -- since we can then use the (unbuffered) sysread()
instead of (buffered) getline().
r168094.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
