From: Andreas K. <andreask@ActiveState.com> - 2004-09-10 21:43:06
|
This post is a consequence of a discussion on the chat we had, and I posted the raw discussion of that here as well. It just has not arrived yet (at least not here). > I'm having difficulty following the rationale > for why this enhancement is needed. I think > that's just due to a lack of background > knowledge in the relationship between Tcl_Channels > and threads and notifiers (oh my!). Yeah. The big stuff in the core. > Perhaps someone could sketch out an "Intro to..." > page either on the Wiki or as an Informational > TIP. > In particular, it's not clear to me why a channel > drive would need to keep per-thread state. Are > these really just multiple copies of the same > per-process data? And is it really "state" > data that will change over the lifetime > of the driver? Or just a set of values that > need to be initialized, but will be constant? Summary: The notifier for windows (and mac) gets one event source for files, and one for sockets, per tcl-thread. Also for serial channels, pipes, console, etc. These sources place events only on the queue of their thread. The sources have to know which channels to monitor for events. Thus needed are a) a per-thread lists of the channels given to the thread. b) or a global list which is searched for channels belonging to the thread. This has to be mutex-locked during search to lock out changes. This is done _often_, each iteration of an eventloop in any thread. (b) should be quite underperforming. So yes, the notifier design for windows (*) seems to force thread-state on channel drivers. On unix the notifier has one shared notifier thread doing a 'select()', and dispatching the incoming events to the proper threads/queues (somehow). Only one event source for timers. (*) And the notifier design was likely forced by the Win API. More details: This is actually different for the various in-core drivers. There are only two drivers which have thread-state: file, and socket. It is also different for the platforms: unix win mac ---- --- --- file yes yes yes socket - yes yes serial - yes ? ---- --- --- Files The file thread-state is a list of structures describing the channel (the instance data). It basically remembers which files are in which thread. On unix the data is relevant only for fd to channel matching. This could be done with a global list, mutex locked when modified and searched. The unix notifier also has a single thread, to select() for all channels. On windows it creates one event source for files per thread. Sockets The mac state is a simple list. It creates one event source for sockets per thread which polls on the sockets if the thread has sockets. The windows state is simple list, plus some common data This common data contains a 'socketThread' reference. It creates one special socket thread per thread using sockets. It also creates one event source for sockets per thread. Serial, Pipe, etc. see sockets. -- Andreas Kupries <andreask@ActiveState.com> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |