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]