Here is the more meaningful part..... Here may be requirements to map to: a) Publish entire set of 'resettable, time-guarded' abstractions. b) Support m watchdog threads watching n handlers. c) Publish your 'resettable, time-guarded' as a pluggable service/block. Handlers should not do this: foo = new SomeResetableTimeGuard();
Please find attached an abstraction contract that makes sense to me. Please use it if you like. Here is the somewhat less meaningful part.... Noel do you realize that watchdog abstractions has never been completely posted by either you or Peter. You have mentioned 3 abstractions. (a) watchdog, (b) target, and (c) factory. Is that true ? Has it ever been posted ? Wouldn't you want to make a service instead of factory in line with component oriented model used in rest of code ? Here is my source of confusion: > > Peter: Are you saying we should always have this strategy > > One additional thread per handler to watch for timeout? > > Yes, that's what is being said. and later .. > proposal is that BOTH the dual-thread and shared thread > implementations would be available under the same interface. Former is the part that I don't agree with. Why will there be 2 implementations if the proposal is saying James will always have 'One additional thread per handler to watch for timeout?' Anyway if you have a mapping from watchdog to scheduler, please post it. It was not obvious to me how a watchdog would identify a particular handler if it was watching more than one handler. There does not seem to be a handler id concept in the abstractions sent. > > Hello? Harmeet? I feel like I'm doing a vaudeville routine with you. Let us talk interfaces instead and get a solid interface set that everyone is happy with. > > Gee, I'd like to fix this memory consumption problem. How about you? Me too. :-) Harmeet
ResettableTimeGuardedCommandMap.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
