From: Jim Kjellin <jim.kjellin@sciron.se>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Tue, 13 Apr 1999 17:13:02 +0200

RE: Multithreaded Event Queue Followup

> > #1:
> > make local socket file descriptor inside the library for each
> > queue. on poll with NULL timeout, obtain a queue mutex, check queue
> > for contents, release mutex, enter select() with special file
> > descriptor in the select set;
> > 
> > on eventSend, obtain mutex, insert event, release mutex, write a byte
> > on the socket file descriptor.
> > 
> > thread in select wakes up, do FD_ISSET() and if it was the socket file
> > descriptor, return immediately, else follow normal copy-event-to-queue
> > procedure.
> > 
> > #2:
> > construct new thread within the library which sits in select() loop
> > feeding all event queues. only lock queues for an instant, during an
> > insert or a remove.
> > 
> > make a pthreads condition variable on each queue, and when someone
> > polls an empty queue, put them to sleep on the condition.
> > 
> > whenever anything inserts an event, from eventSend() or from select(),
> > do a notify() on the condition.
> > 
> > #1 could introduce a number of new file descriptors and involves more
> > system calls, #2 is somewhat more convoluted and has a new thread
> > running around in your library.
> 
> Yes, #1 is what I had in mind. #2 is out of the question due to the
> kludgy and broken way pthreads are implemented on most UNIX variants.
> You simply can't use pthread functions in a library if you want the
> library to work with non-threaded applications. Because of this we are
> even going to implement our own mutexes for the next beta.
> 
	Hmm.. if you consider non-unix platforms (win32 being one) then
using
	select isn't such a good idea either (there are computers without
tcp/ip
	and in the win-world select is implemented in those libraries
	only, AFAIK anyway...
	Use semaphores perhaps?

	--- Jim Kjellin