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
