I think the problem is in `standard-input-port` from `rnrs/io/ports-6`. If you use `current-input-port` instead of `standard-input-port`, does the client behave correctly?
At Sun, 14 Sep 2014 08:20:26 -0500, Brett Stahlman wrote: > On Sep 14, 2014 7:56 AM, "Matthew Flatt" <mfl...@cs.utah.edu> wrote: > > > > It's possible that something is wrong with `sync` and TCP ports --- > > although the test suite at least includes that combination --- but can > > you provide a complete program? > > > > For example, I'm interested in what `handle-rdy-to-send` does. In the > > part that you show, the function will be triggered when one byte is > > available on stdin. If `handle-rdy-to-send` tries to read more bytes > > than are immediately available, then it can block; i.e., the blocking > > part could be in `handle-rdy-to-send`, not in `sync`. That would also > > explain why using `sync/timeout` doesn't change anything. > > Actually, I know it's blocking in the sync (or sync/timeout) because the > actual code is littered with immediately-flushed printf's, and there's one > right before and one right after the sync call. I will try to put together > a version to send you, though. Would you prefer it with the debug printf's > stripped out? > > Thanks, Brett S. > > > > > Again, that's just an example of what might be wrong other than `sync`. > > A complete program would let us sort out the possibilities. > > > > At Sun, 14 Sep 2014 06:57:34 -0500, Brett Stahlman wrote: > > > Hello, > > > > > > I have the following loop in a tcp client program that sends forms > typed by > > > user at the terminal to a listening server, and receives such forms > typed by > > > other clients (broadcast to all clients by the server). > > > > > > (define server-msg-evt (wrap-evt in handle-server-msg)) > > > (define rdy-to-send-evt (wrap-evt (standard-input-port) > handle-rdy-to-send)) > > > > > > (let loop () > > > (sync rdy-to-send-evt server-msg-evt) > > > (loop)) > > > > > > The problem is that the server-msg-evt isn't reliably ready when the > server > > > flushes a message. I know the messages are being sent and flushed > properly > > > by > > > the server because if I type a new form on stdin and hit enter, I see > the > > > following sequence: > > > > > > 1. Client processes new stdin form in handle-rdy-to-send > > > 2. Client loops and calls sync > > > 3. The server-msg-evt is *immediately* ready, and client handles the > > > message in handle-server-msg. > > > Note: The message handled in step 3 may have been sent long before, but > > > the client remained blocked in sync until the (unrelated) stdin event > > > unblocked it. > > > > > > The really weird part is that the client blocks in this manner even if I > > > change the sync to a sync/timeout! > > > > > > Any clue as to what could be going on here? I'm running both client and > > > server > > > in a DOS box on a Windows 7 machine. > > > > > > Thanks, > > > Brett Stahlman > > > ____________________ > > > Racket Users list: > > > http://lists.racket-lang.org/users > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
