FFI: number of worker threads?

Seth Kurtzberg seth at cql.com
Wed Jun 21 12:11:22 EDT 2006


Simon,

Thanks for the info.  I don't compare thread IDs.  At the moment I merely print out the thread ID in a trace message.  Shortly I will be using the thread ID when a need arises to kill a thread.  It sounds like the rollover is harmless for these situations.

When you talk about comparing thread IDs, are you thinking that one might compare two thread IDs to see which one is more recently spawned?  I can see where you might have a situation where you would compare thread IDs to determine whether two somehow related values "belong" in some sense to the same thread.  I'm curious about why one might compare thread IDs in such a way that the rollover would cause the comparison to produce the "wrong" answer.

Seth

On Wed, 21 Jun 2006 12:48:42 +0100
Simon Marlow <simonmarhaskell at gmail.com> wrote:

> Seth Kurtzberg wrote:
> > Another related question.  I have some threaded applications running
>  > which are servers and run continuously.  A thread is spawned for each
>  > new connection, and the thread exits when the client terminates.
> > 
> > I've noticed that the thread ID increases.  On one process I checked
>  > today I am up to thread number 3300.  The number of running threads
>  > is not increasing; only six threads are running on this particular 
> process.
>  > The threads are cleaned up and exit.  The thread _ID_ is continually
>  > increasing.
> > 
> > Is this going to cause a problem when the thread ID exceeds some value?  Do I have to force the server process to recycle periodically?
> > 
> > These processes are designed to run continuously, and are running in a fairly demanding commercial environment for extended periods of time.  They have proven to be very stable and reliable.  I'm hopeful that it will not be necessary to recycle to force the thread ID to restart.
> 
> The thread ID assigned to new threads will wrap around when it reaches 
> 2147483647.  In 6.6 we made thread IDs 64 bits, so you get a bit longer 
> before they wrap around.  Even if you manage to wrap the thread ID, 
> it'll only be a problem if you actually compare ThreadIDs.
> 
> Cheers,
> 	Simon
> 


More information about the Glasgow-haskell-users mailing list