$Bill Luebkert <> wrote: > Brian Raven wrote: > >> Sorry $Bill, perhaps I am not making myself clear. I was not pointing >> out that alarm exists for the purpose of solving the OP's problem, >> but simply to counter your statement that it didn't exist. > > If exists is the key word here - you are right, but like I said it's > not really an alarm. It's a kludge for Win32 that only works in a > limited scenario. As far as I'm concerned, it's not alarm but more a > time poll function.
I think we sort of agree here, but I am not clear what you mean by "a time poll function". > >> Perhaps you should check the man page for alarm. I have just checked >> the Solaris 5.8 man page and it clearly says that there is only one >> timer per process. It also says that if you call alarm from a bound >> thread, using the Solaris threads library, that the signal will be >> delivered to that thread. However, it also says that that behaviour >> is buggy, and is about to be replaced by the standard (POSIX threads) >> behaviour of delivering the signal to the process, which is also the >> case if you use the pthreads library. > > And your point there ? I haven't used Solaris in a while, but it > looks like they're going to clean it up. The point is - you can use > alarm in a threaded env on UNIX. There are a lot of variables > involved, but it's there and it really is an alarm rather than a time > poll. There are lots of different thread libraries on lots of > different OS's and probably the POSIX approach will unify things. Well, of course. Many things are possible, but that doesn't make it a good idea. > >> So, you can only have one timer active, and you can't guarantee which >> thread the SIGALRM will be delivered to (unless you have set up your >> thread signal masks appropriately), which isn't much use if you want >> 'timeout' functionality in multiple threads. > > Did you catch the part where I said multiplex the alarm signal ? > You can catch the alarm in the main thread and signal with another > signal to the child thread. I admit it's not totally straight > forward, but anyone using threads is probably used to having to work > around these kinds of issues. Having had to support legacy C code that did something very similar I would say that "not totally straight forward" is an understatement. > >> Sorry $Bill, but just to make it clear, I am just countering your >> statement "so if you're on UNIX you'll be fine", which I don't >> believe to be true. I have done a fair bit of multithreaded >> programming on a number of platforms, and the general consensus >> seems to be that signals in a multithreaded environment should be >> avoided, indeed, some go as far as to say they are evil. > > I stand by my stmt that you will be fine on UNIX - as long as you > stay within the given functionality of alarm on your platform. > Maybe fine is being a bit light about it and a less optimistic word > would be more appropriate. But with a little research and some > coding, you should be able to implement what he was asking for. The > point is that there is a real alarm on UNIX and you can find a way to > use it properly in a threaded env. 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. > > But that's Solaris, he may be on Linux or whatever. So obviously he > has to read some man pages to see what he's got available. > The poster has probably figured out that it's more trouble than what > it's worth by this point in time, but at least we've given him a > little insight into alarm. I certainly hope that he has given up un alarm by now :-) HTH ================================= Atos Euronext Market Solutions Disclaimer ================================= The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of Atos Euronext Market Solutions. L'information contenue dans cet e-mail est confidentielle et uniquement destinee a la (aux) personnes a laquelle (auxquelle(s)) elle est adressee. Toute copie, publication ou diffusion de cet email est interdite. Si cet e-mail vous parvient par erreur, nous vous prions de bien vouloir prevenir l'expediteur immediatement et d'effacer le e-mail et annexes jointes de votre systeme. Le contenu de ce message electronique ne represente pas necessairement la position ou le point de vue d'Atos Euronext Market Solutions. _______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
