[GUI] Another call for votes

Wolfgang Thaller wolfgang.thaller@gmx.net
Mon, 17 Mar 2003 23:11:58 +0100

Nick Name wrote:

> On Mon, 17 Mar 2003 22:45:07 +0100
> Wolfgang Thaller <wolfgang.thaller@gmx.net> wrote:
>>  	4d) First wait and see if 4c is implementable; if not, fall back
>>  	to 4b.
> Well, I agree on everything and would directly vote for 4b, but instead
> I ask: what is the true problem here? If callbacks are serialized,
> what's the problem in allowing any thread to call CGA functions?

Well, even if the callbacks are serialized, we're back to full 
concurrency as soon as people want to use forkIO in their applications. 
So if you forkIO, do some calculation, and then try to display a dialog 
box when the calculation is finished, you can either rely on 4c or do 
some interthread messaging to fulfill the requirement that everything 
is called from one thread.

If the windowing system allows everything, we get thread-safety for 
free, but if it doesn't allow it, we might have to do some work to 
achieve it in the CGA. The amount of work required will be different 
for different backends.
Some people have doubted that this is easy enough for us to implement, 
but personally I don't see why. I've added 4d to the list because I 
feel that it will be hard to convince them at this early stage, and we 
lose nothing by postponing the decision.

> There
> is a chance that some windowing system allows this. For example, mutual
> exclusion could be required for drawing on a surface, but not for
> registering a callback, so while a thread is drawing, another could be
> allowed to register callbacks.

Yes. Other toolkits will just assume that there is only one thread 
talking to them, so everything will need mutual exclusion. Yet other 
toolkits will allow concurrent drawing to two different windows, but 
will crash when you try to open a dialog box while another thread is 
handling events. And so on.
That's what I don't like about 4a and 4b: It will be next to impossible 
for application programmers to add thread-safety, because the 
requirements are platform dependent.

Of course, 4c doesn't mean that the user will no longer have to 
synchronize anything - you still have to protect your application's 
shared state.