Re: [paragui-users] Puzzled newbie question

[Alexander Pipelka]

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