So the scenario here involves a multi-threaded HTTP server. At high level I am accept()ing socket connections in the main thread (via HTTP::Deamon) and passing the fileno of the returned handle to a thread in a worker pool. I use the fileno as perl (or perhaps ActiveState's perl) is unable to pass the file handle class. I then use the fileno in the child thread to re-open the file with using the fileno. However as soon as the main thread moves on to the next connection/request (and the file handle drops out of scope) the file is closed... even though the worker thread is still attempting to use it. I have attempted to re-bless the file handle to UNIVERSAL to prevent the DESTORY function from firing to no avail. Does anyone know how I might prevent this close-on-destroy behavior from trigger. Pseudo-code as follows:

sub mainThread
{
	my $d = HTTP::Daemon->new();

	// $c is a descendent of IO::Handle
	while ( my $c = $d->accept )
	{

		// pass fileno($c) to a thread-shared queue where it will be picked 
		// up by a worker thread

		// at the close of this loop $c drops out of scope and the socket is 
		// closed, even though the workerThread is still using it
	}
}

sub workerThread
{
	my $fileno = shift;

	my $c;
	open $c, '+<&=' . $fileno;

	// generate a response and write to $c

	close $c;
}

The only solution I have found involves maintaining a list of handles in the main thread and dropping them after the worker thread indicates it is done, however there must be a cleaner way to do this.

Thanks in advance for your help!