"Martin v. Löwis" <martin at v.loewis.de> writes: > David Bolen wrote: > > On Windows, I miss the ability to mix in serial port I/O the most, > > since many of my servers are translators between the network and > > serial devices. > > Do you know whether IOCP could be used with the serial ports? I normally use overlapped I/O with my own WaitForMultipleObjects loop, but IOCP should work just as well, since access to a serial port is just another system handle (the port is opened with CreateFile just like normal files) under Windows and you just use Read/WriteFile to process the data stream. IMHO, Windows is arguably more consistent across multiple types of objects than Unix's "everything is a file" approach. With something like Windows WaitForMultipleObjects you can include handles to system objects for files, semaphores, events, processes and threads, timers, etc... many of which are concepts that don't fall neatly into a select() call under Unix. The rub of course is that sockets are the odd man out, and really feel bolted on afterwards in Windows (you can read/write to them as file handles, but not select them directly with the Wait* operations). If you're just staying with Windows, you can map sockets to a compatible object to use with other system objects, but going in through select() locks you in to sockets only. For my part, in terms of integrating non-socket sources, I'd probably be just as happy if Python permitted it's own Queue.Queue to be selectable, since then I could just have a separate thread with a native Win32 wait object loop, pumping information into the queue. But the basic nature of the fundamantal threading constructs Queue is built on would probably make that difficult, if possible at all. -- David
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