I don't see a problem with this code if it is executed in separate thread context and if you can anytime release a lock by signalling from another thread context.
Well, it would be VERY bad if this code would be called from the main thread :). IMO it's not bad to set wait timeout to infinite, you just need to know how to handle this situation. What if you are waiting for a really long operation and you really need to be able to finish it? It's very hard to set correct long timeout which will satisfy all the possible cases. Better let the user to be able to cancel the task anytime he wants.
Linas Naginionis No one infinite waits for events in main thread. Using threads, WaitForMultipleObjects makes a magic. Any waiting operation can be canceled - it is not problem.
Not a good approach, agree. I've written code such as this but only in test code, not in production software.
ReplyDeleteIt is much better to crash a program with a descriptive exception after a long timeout than to wait indefinitely.
I don't see a problem with this code if it is executed in separate thread context and if you can anytime release a lock by signalling from another thread context.
ReplyDeleteIf the code is well-written it is not a problem.
ReplyDeleteLinas -- those are pretty big if's. ;-)
ReplyDeleteWell, it would be VERY bad if this code would be called from the main thread :). IMO it's not bad to set wait timeout to infinite, you just need to know how to handle this situation. What if you are waiting for a really long operation and you really need to be able to finish it? It's very hard to set correct long timeout which will satisfy all the possible cases. Better let the user to be able to cancel the task anytime he wants.
ReplyDeleteThe alternative is a polling loop, but you've got to be careful about those, as they can quickly go wrong.
ReplyDeleteLinas Naginionis No one infinite waits for events in main thread. Using threads, WaitForMultipleObjects makes a magic. Any waiting operation can be canceled - it is not problem.
ReplyDelete