![]() |
Regards, Marcin
* Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [070222 15:08]:
I wouldn't characterize my approach as "blind". When we get to a job.remove() and the job is not on a list we have two options: skip the job.remove and deal with the consequences or die with the assert error.
I realize your approach isn't "blind" in that sense. But your not dealing with the consequences. You're choosing to just accept the fact it's not on a list and skip handling it.
The real problem came earlier - we shouldn't even be considering a job.remove if the job isn't on a list in the first place. However, the asynchronicity makes faxq rather difficult to debug on rare timing issues like this.
But if the job isn't on a list, it *should* have been. That *is* the real problem. There are very few instances when a job shouldn't be on a list, and those instances are (or at least should be) in known transition points.
If there's a problem with faxq, I'm interested in seeing it, and I want
to get to the bottom of it. faxq *should* be rock solid, without
papering over bugs.
____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*