Hi Jon, I changed alarms a bit after thinking about your problem. First off, repeated alarms that throw an exception get stopped now. If you prefer to handle the exception inside the alarm it will of course get rescheduled; only uncatched exceptions cause a repeated alarm to get cancelled. Secondly, alarms had no way to cancel themselves. One terrible way to solve this is to have your alarm throw an exception, which will now cause it to stop (see above). Exceptions should not be used for control flow. Another way to solve this problem is to pass the alarm to the alarm quotation as a parameter, but this involves stack juggling in your handler quotation and is unnecessary in most cases. So the solution I implemented is storing the currently executing alarm in SYMBOL: current-alarm, and you can do 'current-alarm get cancel-alarm' inside your alarm quotation if you wish.
As for stopping the computation thread, unfortunately, Factor's threads are not preemptive, so you can't cancel your worker thread in the middle of a computation. However, that thread can poll a data structure that your alarm quotation sets once the stream is closed and then call 'stop' inside your worker thread. The only drawback is that you have to finish the current work -- you can't stop early, before some amount of work is calculated. Please let me know if this answers your question. You'll have to bootstrap again to get the current-alarm symbol changes. Doug On Nov 23, 2009, at 12:45 PM, Jon Harper wrote: > Hi everyone, > I have a question about threaded-servers: I need to send an object's > state to a connected client every 100 milliseconds. I'm using alarms > to do it and I'm having trouble canceling it once the client > disconnected. I subclassed threaded-server, and I've overridden > handle-client* so that it registers the alarm and goes into an > infinite loop. The infinite loop is a complex word calculating the > state of the object over time. The sending of the state to the client > should only happen every 100 milliseconds, independently from the > calculations. > > I'm using "[ ] with-disposal" in handle-client* to try and cancel the > alarm when the client disconnects but since the infinite loop doesn't > do any I/O (it's all done in the alarm), it never throws an error when > the stream is closed, and it also never returns, so dispose is never > called. > > Can anyone think of a simple solution to this? > > Thanks in advance. > > -- > Jon Harper > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Factor-talk mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/factor-talk ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
