POSIX version of epicsThreadCreate needs to enable code calling pthread_attr_setstacksize
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
Low
|
mrk |
Bug Description
> Andrew wrote:
> Divide that remaining 2GB by the stack space allocated for
> each thread and you'll get an estimate of the maximum
> number of threads that you can run in a single process.
>
> In our case (Red Hat), the default stacksize is 10240
> Kbytes per thread, which gives a limit of 204 threads.
>
> # Limit stacksize for Linux to increase number of threads
> # 10240 is 204 threads (default)
> # 4096 is 512 threads
> ulimit -s 4096
Some comments:
o I had to read this a 2nd time to see that this is 4096 KBytes (not Bytes) per thread.
o this is virtual, and not actual space used in the page file
o the actual space used by each thread is probably two to three orders of magnitude smaller
> Dirk wrote:
> That means, that CA is not scalable any more (?)
>
Contrary to my previous concerns, it appears that a 64 bit Linux system will *not* be required for large gateways, and that CA scales just fine if one changes the "ulimit -s" quota. This fits with our experience with vxWorks where IOCs are routinely used with more than 200 circuits (within 32 MByte non-virtual address spaces).
Its starting to appear that the root problem is that the posix version of epicsThreadCreate needs to call pthread_
Original Mantis Bug: mantis-143
http://
An update on the results from epicsMaxThreadsHost on windows:
o On W2K the maximum is always 2000 threads. PARAM_IS_ A_RESERVATION is specified when spawning the thread, and 2000 otherwise.
o On WXP the maximum is 30,000 if STACK_SIZE_
I will be changing the windows version of epicsThreadCreate to use STACK_SIZE_ PARAM_IS_ A_RESERVATION.