I suspect -- and it is nothing more than a suspicion, I've not run the code, just read it and Athanasius' reply above -- that by the time you are calling $[e|o]thr->close(), the threads have already committed suicide, because they've finished reading and fallen off the end of fhreader() calling threads->exit(); on their way through.

And, if I'm correct, the later attempts to join those threads is resulting in the panic (in the version of perl you are using) or at least an attempt to use or clean up a variable that has already gone to the bit bucket. And from the wrong thread to boot.

I can't offer more at this time as:

1. I don't have 5.16 installed here.

   It would be a not inconsiderable amount of effort to do so; and right now I'm up to my eyes in stuff that leaves me with little mental capacity for looking at onything else. (I just happened to have a hour or so to kill whilst stuff runs :)

2. I've never used threads->exit.

   It is one of a set of belated extensions to the api that have never seemed to be in the spirit of the original module and I've never found the need to use.

   In addition, every piece of code I seen that did make use of those belated extension to the api has exhibited weird problems.

In your case, as the next thing you do is to fall off the end of the threadproc -- which as the description of threads->exit() states is: "The usual method for terminating a thread is to return() from the entry point function with the appropriate return value(s).", there seems no benefit to calling it.

Having typed that lot, I further suspect that exit fails to initialise any return value; and it is the absence of that that causes the failure when join is called.

If I'm right, the simple answer is just discard the calls to threads->exit.

However, you are also make extensive use of condition variables and signaling. These are something else that I've studiously avoided because, back in the early days at least, they were as flaky as Adobe software. And even a lot more recently they were still apt to cause problems.

I developed a set of methods that avoided them for the most part and have never seen the need or benefit in moving away from them.

All of which is just to say; even if removing the threads->exit works, I have no confidence in the rest of the code working as required, because of its dependence on cond_* calls and my lack of knowledge regarding their current state of reliability.