Gordon McMillan wrote: > > Alexandre Ferrieux wrote: > > > The Tcl solution to (1.), which is the only real issue, is to > > have a separate thread blockingly read 1 byte from the pipe, and > > then post a message back to the main thread to awaken it (yes, > > ugly code to handle that extra byte and integrate it with the > > buffering scheme). > > What's the actual mechanism here? A (dummy) socket so > "select" works? The WSAEvent... stuff (to associate sockets > with waitable events) and WaitForMultiple...? The > WSAAsync... stuff (creates Windows msgs when socket stuff > happens) with MsgWait...? Some other combination? Other. Forget about sockets here, we're talking about true anonymous pipes, under 95 and NT. Since they are not waitable nor peekable, the only remaining option is to read in blocking mode from a dedicated thread. Then of course, this thread reports back to the main MsgWaitForMultiple with PostThreadMessage. > Is the mechanism different if it's a console app (vs GUI)? No. Why should it ? > I'd assume in a GUI, the fileevent-checker gets integrated with > the message pump. The converse: MsgWaitForMultiple integrates the thread's message queue which is a superset of the GUI's event stream. -Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4