Fortunately I can't imagine I would ever actual use thread-sleep! like this, rather the thread would be waiting on I/O, so it appears I have no obstacles.
Thank you for taking the time to look at it. On Sat, Dec 7, 2013 at 2:16 PM, Christian Kellermann <[email protected]>wrote: > * Christian Kellermann <[email protected]> [131207 21:11]: > > Hi Michael, > > > > * Michael Greenly <[email protected]> [131207 20:23]: > > > My assumption is that the thread would be started and recurs until done > > > becomes false at which time that thread would exit cleanly and allow > the > > > join in the primary thread to continue. > > > > > > The 'done' flag only becomes false when INT is signaled and handled > > > > > > Instead I get a "Error: uncaught exception: #<condition: > > > (join-timeout-exception)>". > > > > This may be a bug you have found. If you run the example in csi > > withtout the signal handler and set done to #t it works as expected. > > > > However as I see the thread is found in a "blocked" state when the > > signal handler gets called. This in turn causes the timeout condition > > to be raised. This shouldn't happen as I understand it, as the user > > clearly didn't set any timeout. > > Ah well the blocked state probably originates from being in > thread-sleep!... Removing that makes the example work as expected > modulo the busy loop... > > So the question is how do we determine whether we actually ran into > a timeout... > > (Am I thinking out loud again?) > > -- > In the world, there is nothing more submissive and weak than > water. Yet for attacking that which is hard and strong, nothing can > surpass it. --- Lao Tzu > -- Michael Greenly http://logic-refinery.com
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
