Brian Raven wrote: > I think we sort of agree here, but I am not clear what you mean by "a > time poll function".
I may be wrong here, but I believe what they did on 5.8 or thereabouts was to add some code in the main processing loop to check if an alarm was active and basically take a time difference from now back to when it started and see if it exceeds the alarm time. There are several problems with that approach and the biggest one is getting locked up in an IO wait condition and not getting back to the main loop (which basically disables alarm altogether for that case - which is part of the reason I said there is no alarm on Win32). > Well, of course. Many things are possible, but that doesn't make it a > good idea. In the case of Win32, that's a very sensible tact. > Having had to support legacy C code that did something very similar I > would say that "not totally straight forward" is an understatement. Probably so, but it's an OS issue - some will be easier than others. > I think we shall have to agree to disagree, in that case, as I stand by > my opinion that using signals in threaded applications is not to be done > lightly. It is to be avoided if at all possible, and is certainly not > fine. Just to show that there are others with similar opinions, see > http://www.faqs.org/faqs/threads-faq/part1/, particularly question 10. As long as you have that lightly qualifier there, I'm good with that. > I certainly hope that he has given up un alarm by now :-) Since he's on Win32, I concur. _______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
