2011/2/8 Jakub Piotr Cłapa <jpc...@zenburn.net>: > On 07.02.11 16:19, Jay McCarthy wrote: >> >> I don't know much about Chrome 10, but is it possible that it has >> dropped support for the old framing mode? The WebSocket implementation >> supports both old and new, but defaults to old because that's what a >> lot of browsers (used to) default to. >> >> Look at framing-mode in the documentation. > > The connections work fine most of the time so I do not think this is a > problem with handling of the protocol itself. Sorry, I should have been more > explicit about this in my e-mail. > >> It is unlikely that they are being garbage collected, because it uses >> the same "connection manager" machinery as the Web server, that >> retains references to the ports. > > Does this machinery kill its threads without warning?
Yes, they have timeouts. > Like shutting down the > custodian after the tcp sockets get closed by the other end? Yes. > > After inspecting the source code for ws-closed? it also seams to me there is > no way to find out if a websocket was closed but without proper handshake. > Maybe ws-closed? should also check whether the underlaying sockets are open > or the ws-send and ws-receive calls could change the ws-conn state on any > tcp error? > > The problem can get magnified by the fact that AFAICT ws-close! will not be > able to set ws-conn-closed? to #f if there are errors in the shutdown > sequence (i.e. if write-byte throws an exception). That sounds right... do you want to do patches/test cases? Jay > > -- > regards, > Jakub Piotr Cłapa > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
