user control over stack size for callback invoking threads

[Jeff Hill]

From: Urakhchin, Aleksandr F.

> I had a method allocating 4M buffer as local variable.
> In this case application crashed. I have a quick question about this
> situation. Is it difficult to control thread stack size
> dynamically?

Additional information:
Well, one option I can imagine would be an environment variable that determines the stack size of CA's callback invoking threads. The negative always with this sort of thing will be increased complexity including a longer user manual to negotiate. A similar issue will of course exist with many other callback invoking threads in other libraries. I suppose that we could implement some new function in libCom that returns the proper system wide stack size default for all callback invoking threads internally based on a new environment variable?

Original Mantis Bug: mantis-174
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=174

[mdavidsaver (mdavidsaver)]

For a special situation like I'd suggest using the epicsThreadPool API to create a private thread pool with the appropriate worker stack sizes. I see no reason to expand the configuration of the CALLBACK processing threads.