chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Hang problem with the http egg.


From: Alan Post
Subject: Re: [Chicken-users] Hang problem with the http egg.
Date: Wed, 12 Mar 2008 10:30:28 -0600

On Wed, Mar 12, 2008 at 08:45:31AM -0700, Robin Lee Powell wrote:
> On Wed, Mar 12, 2008 at 08:22:48AM -0700, Robin Lee Powell wrote:
> > If something is choking on the lack of newline, it's in the http
> > egg.
> 
> Except apparently not; apparently it's quite a bit lower-level than
> that.  Here's some code I added:
> 
> (let loop ()
>   (format #t "eof: ~A.\n" (eof-object? input))
>   (format #t "ready: ~A.\n" (char-ready? input))
>   (format #t "peek-char: ~A.\n" (peek-char input))
>   (cond
>     [(eof-object? input) noop]
>     [(format #t "read-char: ~A.\n" (read-char input))
>      (loop)]))
> 
> What's happening is that eof never returns true, even though the
> port is closed.  ready returns #f, and the next operation (either
> peek-char or read-char, I've tried both) hangs.
> 
> Here's the output:
> 
> eof: #f.
> eof: #f.
> ready: #t.
> peek-char: O.
> read-char: O.
> eof: #f.
> ready: #t.
> peek-char: K.
> read-char: K.
> eof: #f.
> ready: #t.
> peek-char: ,.
> read-char: ,.
> eof: #f.
> ready: #t.
> peek-char: 3.
> read-char: 3.
> eof: #f.
> ready: #t.
> peek-char: 3.
> read-char: 3.
> eof: #f.
> ready: #t.
> peek-char: 9.
> read-char: 9.
> eof: #f.
> ready: #t.
> peek-char: 8.
> read-char: 8.
> eof: #f.
> ready: #t.
> peek-char: 4.
> read-char: 4.
> eof: #f.
> ready: #t.
> peek-char: 3.
> read-char: 3.
> eof: #f.
> ready: #f.
> [hangs here]
> 
> I don't know why eof never returns true, but I guess the tcp
> connection is still open behind the port.  Closing the port first
> just results in the read failing right away.
> 
> I'm kind of stuck at this point; I can make my own string collector
> that stops when char-ready? is #f, but there seems to be a more
> general problem here.
> 

I have experienced this kind of problem when shutdown(2) is not
used on a network fd, though the precise cases in which it happens
I don't remember for sure.  It could be when the port was dup(2)ed,
which makes sense now that I think about it.

IIRC, a tcp file descriptor, which is open for both reading *and*
writing, doesn't always behave like a file-based fd when clos(2)ed.

-Alan
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]