> > The problem that worries me with that approach is the implementation > on the application developer level. When I create a grid-enabled > application, how will I be able to determine how long my thread will > run so that I know if I should code it to throw/respond to an > occasional progress event?
The idea is that: 1. We set a timeout (the app could set it) 2. We wait for progress to reset that timeout ... If the progress information cannot be determined then the thread's timeout has to be increased. This decision has to be made by the application developer. > > For instance, let's say I have a PocketPC with the .NET Compact > Framework, a 200MHz Windows 98 machine and a 3.2GHz Windows XP > machine. The thread doesn't take long to execute on the XP machine, > but takes much longer on the Win98 machine, and even longer on the > PocketPC. If we're looking purely at a timeout, for most real cases, > the latter two machines will timeout on most every thread. > > Second example: let's say each thread connects to a database server to > perform some operation, and the database server gets overloaded to the > point that it's rejecting connections until the current processes have > completed. Your threads are still alive, but waiting on something > else... if it exceeds some timeout, the thread is killed, and probably > re-sent to another executor which will encounter the same problem. In my mind the idea of the ThreadTimeoutEvent event exists to let the running thread know that we are expecting a status. It was meant to prevent the premature termination of a healthy thread on a slow machine. > > .... > > However, I think I may have missed your point. > > If we require every thread to respond to some AreYouStillRunning > method invocation, and we kill the thread based upon its failure to > respond (which I think is what you meant), that makes sense. The > return value from that method can be completely scrapped; we're merely > interested in _if_ it responded, not necessarily what the response > was. I think that calling a method makes more sense than coding to > respond to a ThreadTimeoutEvent, because we would need to be able to > determine if it responded to the event or not. I am suggesting that a progress report should be sent back because the Manager (or Executor or application) should know if the thread is working. This should also prevent client side implementations of the event that just mimic our heartbeat thread. Once progress information becomes available we could make the Executor or Manager do something about threads that have no progress even if they look alive. > > And, I think it's a completely separate issue from determining if a > thread is still alive, but I do think there should be some facility > for the thread to send arbitrary progress messages back to the Manager > which are ultimately rerouted back to the GApplication. That way an > application could be developed where threads are created and their > processing can be monitored by the application during execution, as > opposed to just knowing that the thread was sent out and that it > completed. I never thought of sending back to the app the progress but it makes sense. > > Sorry if that didn't make any sense... operating on about 5 hours less > sleep than normal. > My explanations are pretty convoluted so I understand why things didn't make sense. Do they make sense now? Sleep debt is creeping up on me too :( http://en.wikipedia.org/wiki/Sleep_debt Tibor ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
