On 6/17/05, Antoon Pardon <[EMAIL PROTECTED]> wrote: > 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.
gtk.main is analygus to a condition. You get signaled when you have some processing to do. When you get called you expect to be able to do the processing that is neccessary. Some (admittadly rather poor) argument can be made that event handlers being called with the lock enabled is an attempt to ensure responsiveness. It would suck to have to aquire the lock for every little event handler. What is the use case for releasing the lock in a callback? Callbacks should be short or cause the responsivness of the whole application to suffer. If a call back is long enough that you are considering releasing the lock (and you are already using multiple threads) you should probably be doing the task asyncronously. > > Except maybe consistent with the original design decision. > > -- > Antoon Pardon > _______________________________________________ > pygtk mailing list pygtk@daa.com.au > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ > -- Christopher Lambacher [EMAIL PROTECTED] _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
