On Thu, Jun 16, 2005 at 01:36:15PM -0400, Chris Lambacher wrote: > On 6/16/05, Antoon Pardon <[EMAIL PROTECTED]> wrote: > > On Sun, Jun 12, 2005 at 10:19:03PM -0400, John K Luebs wrote: > > > > > > > > Now marking the gtk.main() as such a critical section would > > > > mean that all other threads wanting to enter a critical section > > > > with gtk.gdk calls would be stopped from doing so until gtk.main > > > > had quit. That seems less than usefull. > > > > > > > No, because if and when gtk_main sleeps or waits, it will drop the lock > > > at the proper time. This design keeps things consistent. > > > > Well I differ about that. IMO there is nothing consistent about > > having a programmer mark a particular code as critical and > > then have the internals of that code reverse the decision. > This is a common idiom. Conditions and signals come to mind. You > acquire a lock and then wait on a condition. The condition unlocks > the lock. When another thread signals the condition, the waiting > thread is woken up owning the lock.
But we only have two calls available. One equivallent to acquiring the lock and one equivallent to releasing it. So why should I as a programmer who has access to only those calls, view it as a condition variable? The documetation only mentions a GDK lock. As a consequence if I need to remove the lock in a signal callback I have to remove the lock with gtk.gdk.threads_leave(). As a programmer I can't use the logic of a condition variable if I think that would be more appropiate here. So as a programmer looking at it as a condition doesn't make much sense. > Think of event handlers as being in the context of main, but when main > is not doing anything it does not make any sense to continue to hold > the lock, which would prevent you from doing anything in another > thread. The question is, why should the lock already be held when main is called. If main needs the lock, why not let it acquire the lock itself. I guess it has something to do with the design decision to invoke the signal callbacks with the lock on. IMO that was a mistake, but that can't be helped now. But I can't agree in calling the consequences of that decision somehow consistent. Except maybe consistent with the original design decision. -- Antoon Pardon _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
