Sounds right to me since it mirrors the solution used to enable XHR from workers. -Darin
On Tue, Dec 8, 2009 at 11:25 PM, Fumitoshi Ukai (鵜飼文敏) <u...@chromium.org>wrote: > Right now, WebSocket uses WebSocketChannel and SocketStreamHandle directly, > but this might not work well if the WebSocket is running on another thread > (i.e. worker threads). > SocketStreamHandleCFNet is expected to run on loader process/main thread, > so attachment 44393 in bug 32214 won't work well on Mac. > Also, we'll want to share global data to maintain current opening channel > to limit the number of opening channel to each destination in > WebSocketChannel class. > > So, I propose to set thread boundary on the WebSocketChannel interface. > I introduce ThreadableWebSocketChannel, which is abstract interface for > WebSocketChannel, and ThreadableWebSocketChannelClientWrapper, which is > ThreadSafeShared class to wrap WebSocketChannelClient. > > ThreadableWebSocketChannel::create() will create WebSocketChannel on the > main thread, or create WorkerThreadableWebSocketChannel on the worker > thread. > > WorkerThreadableWebSocketChannel has a bridge between the worker thread and > the main thread. It uses WorkerLoaderProxy to communicate between the > threads. > > WebSocketChannel and SocketStreamHandle always runs on the main thread. > > http://docs.google.com/View?id=dfm7gfvg_13drnxm3fn > > Is there anything else I should be careful about? > Any comments are welcome. > > Thanks! > ukai > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev