[Problem]
After an Event Heap client aborts a waitForEvent call
because of timeout, the resources allocated in the
server (i.e. EventBlocker) to process the request still
remain.
In case that the client had a loop to call waitForEvent
with a short timeout to do something periodically (e.g. to
check some state variable, to make feedback to the
user), this behavior would bring a serious problem;
EventTracker breeds unlimitedaly (one for each
waitForEvent call) until any matching event appears, and
they result a burst of useless reply packets to the client
when one matched.
[Suggested Fix]
The client tells the expiration time of the call to the
server in some way (e.g. by putting the timeout value
within the waitForEvent request packet) and the server
releases the blocker at the time.
[Workaround]
Until this problem is solved, any long-running
applications should not use timeouts.