Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 12 Apr 1999 21:15:06 +0000

Re: Resent from berlin: woo hoo (#2) (fwd)

Graydon Hoare <graydon@pobox.com> wrote:
> (1) whoever wrote GGI's event system: it's not threadsafe, still! I
> can't inject new events into the queue using ggiEventSend without
> corrupting the queue structure; since this is the only reasonable way
> to have 1 thread tell an event-reader it wants to do some drawing,
> we're back to a polling loop. this "grinds my gizzard"

He's right. Originally I thought that threaded applications could
handle this themselves, but then you can't use giiEventSend() while
blocking in giiEventPoll(). The thread safety is a two minute job to
add in, and for speed in singlethreaded apps I propose that we add a
new function:

int giiMTInit(void)
{
	_gii_threadsafe = 1;
}

and do the locking like this
if (_gii_threadsafe) ggLock(inp->mutex);
do stuff
...
if (_gii_threadsafe) ggUnlock(inp->mutex);

However I spotted a more interresting problem - If you call
giiEventPoll() with a NULL timeout from one thread and then call
giiEventSend() from another thread it might be desirable to have
giiEventPoll return and report the event from giiEventSend.
Should we implement this?

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

Index: [thread] [date] [subject] [author]