what can Monitor::wait() throw?

[andhow]

Referring to pg. 648 of the Ice 2.0 docs, they wrap the increment/decrement in a try catch block, which makes sense if wait() can throw. My question is what does Monitor::wait() throw and in what situations? Does this apply to Monitor::timedWait() as well?

[matthew]

Originally Posted by andhow

Referring to pg. 648 of the Ice 2.0 docs, they wrap the increment/decrement in a try catch block, which makes sense if wait() can throw. My question is what does Monitor::wait() throw and in what situations? Does this apply to Monitor::timedWait() as well?

Monitor::wait can throw a ThreadSyscallException in the event of a system call failure. Under a UNIX system wait ends up calling pthread_cond_wait, which can fail for a variety of reasons -- the most common of which is EINTR. Under Windows it can fail if WaitForSingleObject fails. Typically this does not occur.

In addition to ThreadSyscallException Monitor::timedWait can throw a ThreadLockedException if the lock cannot be acquired.

Regards, Matthew

[andhow]

Ahh, thank you. I know there isn't a black and white answer, but in general, are these the type of exceptions that occur when the system is in a bad state, perhaps it has run out of some threading resource, in which case the application should shut down?

[matthew]

Originally Posted by andhow

Ahh, thank you. I know there isn't a black and white answer, but in general, are these the type of exceptions that occur when the system is in a bad state, perhaps it has run out of some threading resource, in which case the application should shut down?

The MS documentation for WaitForSingleObject is pretty useless in the case of a WAIT_FAILURE error return value. I'm not sure that I've ever seen this error condition myself... so I think it would indicate something very usual has occurred.

As to EINTR, I'm afraid its not possible to give a concrete answer to this without knowing more about your application and its setup. Basically EINTR occurs when the system call is interrupted. If you use signals, and depending how your application sets up the signal state (and whether your flavour of UNIX is POSIX compliant or not) and how it uses signals (I recommend, btw, to stay away from them if at all possible) its possible and sometimes expected for the system call to be interrupted. Is that a sufficiently hand-wavy explanation?

Regards, Matthew

[andhow]

yessir, that gives me a good idea. thanks!