Frank Naumann wrote:
Hello!I'll paraphrase. Basically, I was asking if there was an "approved" solution for an integrated event loop to handle both AES and GEMDOS style events, and what that solution was. Also, if there is no such "official" solution yet, I was suggesting my own. The suggestion, to simply a whole page of information and various reasons for this idea, is to use a device to feed AES events to GEM applications. This removes much of the problems you would have with a pipe, although a socket would still be an alternative, I like the device idea better. You can tell this device what sort of events you want with Fcntl() calls, and then simply wait on the opened file handle.
Requiring use of Fnctl() or any other system call to alter the set of events imposes too much overhead. On servers where the set of descriptors of interest changes frequently, this kind of approach is a serious loser.
Ah, I see. Personally I wanted to go into the kqueue() direction as introduced and used by the BSD systems. This solution looks very easy to use and is extremly flexible and extensible. It's basically a filedescriptor and you add a list of events (determined by id and a filter) you want to wait for.
See this message http://www.openldap.org/lists/openldap-devel/200411/msg00088.htmlkqueue has some other performance limitations as well. The scheme I outline in the above link addresses all of those shortcomings.
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support