Thread::detach() call doesn't return

[Nacho de los Ríos Tormo]

Hi there!

Sorry to be so vague and so wordy at the same time, but I couldn't think of a 
shorter way of communicating my problem without posting the whole code, which 
I figured would not be tolerable to (and would be certainly skipped by) poor 
list readers. I have searched the archives and found no clues: if there are, 
forgive me; I'm really not experienced in c++.

Thanks in advance for your patience.

Nacho de los Ríos

+++++++++++++++++++++++++++++++++

I'm porting an old DOS C program to Linux. It was, predictably, a 
single-thread program, but now that it's moving into Linux, I want it to gain 
new abilities: I'm trying to substitute its former RS232 comms with TCP/IP 
over Ethernet.

I've written a program using commoncpp that takes care of comms this way:

* Define a TCPSocket subclass MyTCPSocket

* Define a TCPSession subclass MyTCPSession that will be instanced once for 
every new connection. MyTCPSession has a static, semaphore protected mailbox 
to communicate with the original DOS single-thread code.

* Define a thread subclass MyTCPServer that aggregates a static MyTCPSocket 
and a vector of MyTCPSession*. It's run() method awaits incoming connections 
and assigns them to a new MyTCPSession.

This is more-or-less how I understood it should be from the examples. This 
code is meant to be called from the formerly DOS code, and amounts to less 
than 400 lines of code.

The whole scheme works just fine with a test main() function that instances a 
new MyTCPServer and then just sits there while new TCP sessions are created, 
checking the mailbox and printing received messages when they are available.

However, when the TCP code is called from the DOS code, it happens that the 
call to detach() in MyTCPServer constructor never returns, and the DOS thread 
sleeps forever. The TCP threads are nonetheless running, new connections are 
happily accepted, and the first incoming message is received. Further 
incoming messages make their receiving threads freeze on the incoming mailbox 
semaphore, as the calls to read the mailbox are in the sleeping or dead DOS 
code thread.

By the way, these threads, though visible with 'ps -A', and easy to interact 
with,  are not seen by gdb's 'info threads'.