river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: What is wrong with TaskManager?
Date Mon, 08 Apr 2013 14:32:33 GMT
On 4/8/2013 6:52 AM, Mark Brouwer wrote:
...
> Therefore I spent some time in analyzing the 4 tasks
> (ServiceDiscoveryManager and JoinManager) that didn't return 'false',
> but I concluded it wouldn't be easy to rewrite those, it requires an
> intimate knowledge of these implementations and I didn't want to burn my
> fingers on that one. On that response of Bob I wrote "I agree I had
> mixed feelings when implementing it (that is runAfter), but now that we
> have it I must admit I can see some use cases for it in our own
> environment. Sometimes you have those event generators that have to
> notify all the listening entities. Notifications you want to have
> performed through a thread pool, but you must guaranty the ordering of
> the events. Of course everything can be implemented in a different way,
> but the runAfter semantics are quite handy for the 'ordinary'
> programmer, opposed to putting the burden on them to arrange for it
> themselves.". I concluded runAfter is *not evil* by itself when properly
> used, although it gives some overhead and it has to perform its work
> while a lock has been held.
...

Thanks for the background. The general performance of TaskManager, and 
especially the overhead for runAfter, seemed to me to depend strongly on 
the queue length. For example, a non-trivial runAfter method scans the 
list of tasks older than "this", stopping if it find a collision. That 
is a fast operation for a short queue length. Did you do any 
measurements of that?

Patricia


Mime
View raw message