On Oct 17, 2003, at 6:59 AM, Andriy Shapochka wrote:
>> 1. EventDispatcher. Any reason why you are not using EventManager from
>> cayenne.event package? I can name a few myself :-), but we are (will
>> be) working on fixing those. Don't know if you remember this recent
>> discussion:
>>
>> http://objectstyle.org/cayenne/lists/cayenne-devel/2003/10/0009.html
>
> Well, I just went for the time-proven and lightweight approach.
> In rich clients everybody is firing all sorts of events all the time.
> So much the better for faster and simpler designs. I should
> think over using cayenne.event.EventManager now, when I have had a
> closer look into it. The one serious drawback of cayenne EventManager
> is its postEvent(...) was declared synchronized, though. Any
> time-consuming
> listener threatens to paralyze the entire (!) EventManager for long.
> A trick similar to the one I use in
> dataview.EventDispatcher.dispatch(...)
> (which is not synchronized but in parts) might help solve the problem
> of thread-safety and avoid the possibility of petrification :)))
> at the same time.
I just checked in an updated version of EventManager that has the
following features:
1. Asynchronous events. This is on by default, but it can be controlled
by calling "postEvent(...., true)" forcing immediate event dispatch in
the same thread.
2. Synchronization is now done by subject. EventManager is no longer
synchronized (so you can post new events while others are waiting in
the queue), but multiple events for the same "subject" are processed in
sequence.
Implementation notes:
EventQueue:
All "asynchronous" event posts are using internal event queue.
"postEvent" will append an event to the queue and exit immediately.
There are multiple DispatchThreads waiting on the queue, so one of them
would be awaken, pop an event from the queue and start processing
dispatch.
DispatchQueue: Another type of "queues" used is DispatchQueue. It
encapsulates the logic to add/remove/read the listeners for a
particular event and sender. EventManager maintains one queue per
subject. Advantages that DispatchQueue brings to the event mechanism,
compared to the 1.0 implementation are:
- It contains explicit data structures for "listeners for events
originating from any sender" and "listeners for events originating from
a particular sender".
- It creates a finer synchronization boundaries (by subject).
- It simplifies EventManager
We need to do some more testing for possible deadlocks (EventManager at
different moments in time synchronizes on event queue, subjects map,
and each individual DispatchQueue... There is no nested synchronized
blocks, and I can't come up with a scenario for Manager deadlock, but
this doesn't mean that it can't happen :-)). Also we may add some
safety mechanisms, like expiring events waiting in the queue for too
long, creating new DispatchThreads when the pool of threads is
depleted, canceling long running dispatches, etc.
Andrus
This archive was generated by hypermail 2.0.0 : Sun Oct 26 2003 - 17:31:41 EST