Dennis Lee Bieber wrote: > Well, at that point, you could substitute "waiting on a queue" with > "waiting on a socket" and still have the same problem -- regardless of > the nature of the language/libraries for threading; it's a problem with > the design of the classes as applied to a threaded environment. It's a problem for all levels; pretty much any of them can botch it. Not only do we want to be able to wait on two queues or two sockets, we might have good cause to wait on two queues *and* two sockets. Win32 provides WaitMultipleObjects which lets the programmer efficiently wait on many objects of various types at one call; the Linux kernel Gurus are looking at supporting a similar feature. Library designers can botch the functionality by wrapping the waitable object in their own classes with their own special wait operation, and hiding the OS object. -- --Bryan
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