Sorry. I didn't notice you were using T::Q::Duplex, and assumed T::Q.
However, I recently had exactly the same symptom, "Bad file descriptor" error, trying to dup IO::Socket::INET handles in peer threads, and I cured it, reliably, by the technique I described.
I'm not familiar with T::Q:Duplex, but I would suggest looking closely at the timing of your code. A few trace statements with HiRes timestamps or simply push a copy of the file handle returned from the accept onto a package scope array and comment out the close. See if it makes a difference.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply] |
You were right...see my update to the OP.
I forgot that TQD::enqueue() doesn't block, TQD::enqueue_and_wait()
does...which also explains my original issue, which relies on Thread::Apartment (also based on TQD) and was using a simplex method
to pass the fileno over to the worker thread (simplex methods
use nonblocking enqueue_simplex(), rather than enqueue_and_wait(),
for the RPC to the apt. threaded object).
| [reply] |
Ah! That explains it :)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply]
[d/l] |