FFI: number of worker threads?

Seth Kurtzberg seth at cql.com
Tue Jun 20 23:22:26 EDT 2006


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.

Seth


On Tue, 20 Jun 2006 22:57:17 -0400
"Li, Peng" <ringer9cs+ghc at gmail.com> wrote:

> Hello,
> 
> The paper "Extending the Haskell FFI with Concurrency" mentioned the
> following in Section 6.3:
> 
> "GHC's run-time system employs one OS thread for every bound thread;
> additionally, there is a variable number of so-called "worker" OS
> threads that are used to execute the unbounded (lightweight) threads."
> 
> How does the runtime system determine the number of worker threads?
> Is the number hardcoded in the RTS or dynamically adjustable?  Can a
> programmer specify it as an RTS option or change it using an API?
> 
> I would like to use a large number (say, 2000) of unbounded threads,
> each calling a blocking, safe foreign function via FFI import.  What
> is supposed to happen if all the worker threads are used up?  I tried
> this in the recent GHC 6.5 and got some kind of "runaway worker
> threads?" RTS failure message when more than 32 threads are used. Is
> it a current limitation of the RTS, or should I file a bug report for
> it?
> 
> Thanks,
> Peng
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


More information about the Glasgow-haskell-users mailing list