[racket] Possible bug involving sync on tcp ports

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" <mflatt at 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