[racket] Possible bug involving sync on tcp ports

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140914/a347c427/attachment-0001.html>