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
