[racket] Possible bug involving sync on tcp ports

On Sun, Sep 14, 2014 at 9:23 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 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?

It does indeed! Can't recall why I used standard-input-port to begin
with, but I'm thinking this could account for some of the weirdness
I've been seeing. I didn't mention it in my original posts, but part
of the reason I went to such a convoluted strategy for peeking and
reading ports was that byte-ready? was blocking as well. Actually,
I've been planning to change the client/server architecture entirely -
to one in which each port reader operates in a dedicated thread, and
simply blocks until a new form can be read, at which point it writes
the data to an async channel to be processed at a higher level - but I
didn't want to proceed without resolving these issues...

Out of curiosity, what is the proper way to set the current input port
to stdin (if somehow it's been changed from the default)? (It hasn't,
in my case, but perhaps the reason I went to standard-input-port in
the first place was that there didn't appear to be any guarantee that
the current input port would be stdin...)

Thanks,
Brett S.

>
> 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