[GUI] GUIs and events (was: Re: Concurrency)

[Glynn Clements]

[Originally sent to FFI.]

Wolfgang Thaller wrote:

> > > 2) CGA implementations should automatically do all necessary
> > > synchronization so that the CGA fully supports concurrency even if the
> > > backend library does not.
> >
> > I suspect that this might be a bad idea, and I'm not totally sure that
> > it's even possible. I think that it would be better to defer this
> > decision until the feasibility can be assessed.
> 
> While different implementations might in some cases be slightly more 
> complex than just using locks, I don't see why it should be impossible. 
> After all, thread-safe toolkits are not new.

But non-thread-safe toolkits still exist. X itself isn't necessarily
thread-safe (thread-safety is optional; AFAIK, XFree86 is thread-safe,
but some other implementations aren't), and toolkits built atop X tend
to be thread-safe only if the underlying X libraries are.

> Do you have any specific problems in mind?

1. You need to run a specific sequence of toolkit operations without
any other operations being interleaved. Even if the toolkit is
thread-safe, the application itself will still have critical sections
with regard to its use of the toolkit.

And if the application has to do its own locking some of the time, it
may be better to just shift the general problem onto the application. 
That avoids substantially complicating the toolkit code for a case
which is seldom used (most GUI programs only call the toolkit from one
thread).

2. Deadlock.

You need to specify enough about the locking behaviour that the
application at least has the possibility of avoiding deadlock.

The most naive approach would be to simply hold a global lock across
all toolkit functions. Of course, that would include e.g. 
XtDispatchEvent, which means that callbacks would be entered with the
lock held, so any attempt to call toolkit functions from within a
callback would either deadlock or fail.

So, that approach won't work. What will work? Do the common toolkits
even specify their behaviour in enough detail that it's possible to
ensure that any given strategy will work?

-- 
Glynn Clements <glynn.clements@virgin.net>