Re: [paragui-users] Puzzled newbie question

[Andrew Ford]

Whatever is done for this, it shouldn't be visible
when you're writing new widgets or event code on the
developer's side.  I think if you use reference
counting, you should be able to do the locking inside
the reference counter.  I'm reading a book "Modern C++
Design, etc... etc..." by Andrei Alexandrescu.  One of
the things he describes instantiating things like
reference counters with "Policy" objects that define
what checks or options take place inside the object. 
For instance:

template < class checkingPolicy = noCheck, class
threadPolicy = noLock > class refCounter
{
  whatever...
}

Then, depending on how you wanted to build this
object, you would instantiate with a functor object
that locked this reference counter on access, or
checked for access to null, or whatever else you
wanted to do with this object.  I know this is
offtopic :), but I thought it was a really interesting
approach to this sort of thing.

Andrew.

--- Alexander Pipelka <address@hidden> wrote:
> Am Mon, 2002-04-29 um 17.31 schrieb Guillaume
> Schmid:
> > Maybe an other idea (I dont know if it is
> applicable :)
> > 
> > >From what I anderstood from the code, the floww
> of operation is like
> > this:
> > a static function
> PG_MessageObject::PumpIntoEventQueue find the widget
> > concerned by the event (by a recursive search) and
> ask this widget to
> > handle the event with PG_Widget::ProcessEvent.
> > 
> > This function does the following:
> > 1 - Acquire it's mutex.
> > 
> > 2 - Ask it's parent or it's children to process
> the event by calling
> > recursively ProcessEvent.
> > 
> > 3 - Release the Mutex.
> 
> Right :))
> 
> > It mean that for each delegation of a parent or a
> children, a new mutex
> > is acqired and released.
> > At the second level, is this necessary to re-lock
> a mutex since we are
> > already in an exclusive section ?
> 
> Exclusive for the parent delegating the event.
> Any widget involved in handling the current event
> will be locked.
> 
> > Is there any cases where the second level on
> locking is mandatory ?
> 
> Sure.
> Think of multithreaded apps sending messages to
> widgets and it's parent
> in parallel (I know, rare cases. But possible).
> 
> > If it is not the case a solution might be to lock
> at the
> > PG_MessageObject::PumpIntoEventQueue function
> (might not be what we
> > could call a fine grained locking but that might
> fix the problem... :)
> 
> That would not solve the problem because the message
> handler would still
> delete the widget.
> 
> I'm currently thinking about an *easy* solution for
> the 1.0.x branch.
> 
> What about this:
> 
> 1 - event occurs - widget gets locked
> 
> 2 - message handler wants to delete the handling
> object (this) and calls
> delete
> 
> 3 - delete operator checks if we are locked and sets
> a flag. widget will
> not be deleted
> 
> 4 - widget gets unlocked - handler checks for delete
> flag and calls
> delete
> 
> For the 1.1.x branch i want to find a better
> solution. I will think
> about that refcounting thing.
> 
> Alex
> 
> 
> 
> 
> _______________________________________________
> paragui-users mailing list
> address@hidden
>
http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com