RE: [Boost-users] boost::thread problem

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-03-17 11:57:35

Pete <petehug_at_[hidden]> wrote:
> I'm having a problem with my boost multithreaded application. 
> My app runs fine as a Windows Service, but as a Unix daemon it
> stops responding after some time. I noticed that the fewer
> threads I have available, the quicker the application stops
> responding: HP-UX(64) after 20mins, RH8(256) after >1hr, Linux
> RH9(1024) >5hrs. This led me to assume that perhaps the threads
> are not cleaned up properly.

That could well be right.  Perhaps there is some kind of deadlock
at thread exit?

> Therefore, I wrote a little test app which ought to demonstrate
> the problem.  To my surprise, the test application showed an
> entirely different problem, but again, only under Unix (it
> works as expected under Windows). I'm totally lost what the
> reason is and appreciate any help.
> 
> Expected:            Actual:
> ---------------      ---------------
> Start running        Start running
> Start swimming       Finish running
> Start cycling        Start swimming
> Finish swimming      Finish swimming
> Finish cycling       Start cycling
> Finish running       Finish cycling
> 
> In windows I get the actual output but under Linux RH9, I get 
> the Actual output. Under RH9, the first five lines of the
> actual output appear immediately, but the last one takes
> approx. 4secs. In other words, only the last threads don't
> sleep the number of secs specified.

According to the manual page:

      "sleep() makes the current process sleep until seconds sec-
       onds have  elapsed  or  a  signal  arrives  which  is  not
       ignored."

(Note that each POSIX thread is/was implemented as a process in
Linux.)

If thread creation involves receiving a signal then that would
explain the above behaviour.  I would expect it under RH8
because that has the old LinuxThreads implementation of pthreads
that uses signals heavily, but not in RH9 which has NPTL.  Still,
you would be better off using boost::thread::sleep() instead.