A queue that contain events inside. Events occur in an asynchronous manner at the OperatingSystem level. The OperatingSystem may respond to events immediately or put them in an EventQueue for later processing.
EventQueues are an easy way to achieve AsynchronousProgramming. Compare with AsynchronousSystemTrap.
The advantages of EventQueues are that they perform well and do not require LockBasedSynchronization. If you think LockFreeSynchronization is a GoodThing, EventQueues are a good match.
A way to achieve AsynchronousProgramming using EventQueues:
Ask the operating system for something. Instead of using the result immediately afterwards, you do other operations and when finished, read an EventQueue. (E.g. via select in Unix systems.)
- The problem with select is that in this case EventQueues are per FileDescriptor?. You must block on select, and therefore other events (in other queues) won't get processed until select times out. This is not a GoodThing. -- GuillermoSchwarz
- Untrue, you can do nonblocking/async I/O with IoMultiplexing (select). It is a very good thing, because you can do purely nonblocking, very tiny timeouts, very long timeouts, infinite timeouts (purely blocking) - whatever you want. The only drawback is that you can't necessarily block on everything you want; e.g. X11 events are not guaranteed to be implemented via file descriptors. But when they are, select is pretty sweet in general. Windows is much more clumsy, requiring a thread per queue to emulate the functionality of select (see cygwin).
- Windows does not require a thread per queue. Maybe cygwin does, because cygwin tries to reimplement Unix on top of Windows, because Windows is considered clumsy, so let us build this wonderful Unix on top of it??? The Windows API is not so bad when it comes to event processing. You certainly don't need to use threads to make it work, that's just marketing. -- GuillermoSchwarz
- What you said about select is true, but Windows has WaitForMultipleObjects? as well, pretty much the equivalent of select.
- WaitForMultipleObjects? does solve the problem, but I sincerely dislike it. It doesn't have an IntentionRevealingName?. It is cumbersome to use. I prefer put and get, just like queues are supposed to work. -- GuillermoSchwarz
- So the thread-per is needed by cygwin only for strict emulation, but when doing native Windows programming, one never needs that, because WaitForMultipleObjects? is sufficient?
- Well, it is more complicated and cumbersome in comparison with Unix select. Strictly speaking, WaitForMultipleObjects? takes a HANDLE*, but HANDLEs to files, sockets, are not allowed to be into that array. Instead asynchronous I/Os can take as input parameter synchronization objects (the result of CreateEvent?), which in turn can be waited with WaitForMultipleObject?, there's also a WaitForMultipleObjectEx? (like with almost any other Windows API) that can wake you up automatically with a special result in case any async io scheduled by the calling thread has completed, so this can also be rather convenient. But again, some people would say that Windows API is more powerful, while traditional select() in Unix has had scalability problems and wasn't considered truly an asyn io solution, therefore you have a flurry of different aio_xxx API in Solaris, Linux, etc. One can say that Windows sacrificed elegance for performance. The developers of cygwin might have been justified to take that route for emulating select, but on the other hand native windows developers don't need to, they are much better off with Windows view of the async IO world.
- Interesting, thanks. Yeah, select sucks if you have more than (some threshold like 32 to 256) file descriptors, that's very true.
- Java still lacks something comparable to select. Channels, AFAIK, are still buggy and hard to use.
- An alternative solution would be that all communication is performed through file descriptors. This requires modifying the OperatingSystem for something as simple as adding a new EventQueue. WinSock (Windows version of BerkeleySockets?) solves that by putting all socket events in the window EventQueue.
All petitions made to the operating system are responded to through the event queue. Each event has all the necessary information (context) to know what to do with the result.
The most obvious advantage of programming this way is that the consumer's responsiveness can be several times faster than when using synchronous programming for the same task. Multiple I/O requests can progress simultaneously, and computation can overlap with them. This is a GoodThing.
Smalltalk/V and SmalltalkExpress are systems that use EventQueues and that are well integrated with Windows in that respect. You should take a look: SmalltalkExpress was free for download and most code is there to look at.
Related: MessageQueue, GuiThread.
CategoryConcurrency CategoryEvents
Event Queue