 |
lua-l archive |
|
|
||
|
I don't believe it's that simple..
Surely it _is_ that simple! I'm not suggesting that everyone will want to set a thread stack size, or even know how to chose one if they feel the urge. So they can just stick with the OS's default. (I was suggesting an _optional_ third parameter to task.create().)
At least in pthreads on Linux, the default is very large -- much larger than is usually necessary, let alone desirable. Received wisdom on the net suggests that it is _very_ much larger than appropriate (and encourages the development of software which blindly ignores its stack requirements and thus isn't as safely portable as might be liked, since one ought to be trying to compute a sensible stack size and stick to it so far as is possible, etc. etc.)
pthread nor _beginthreadex() will hardly disqualify a stack size for being too low.
The MSDN blurb for _beginthreadex() doesn't say, but the pthreads docs say this...
"pthread_attr_setstacksize(): Change the size of the stack created for the thread. The value defines the minimum stack size, in bytes. If the value exceeds the system's maximum stack size, or is smaller than PTHREAD_STACK_MIN, pthread_attr_setstacksize will fail and return EINVAL."
So, my solution in Lua Lanes was to pick "suitable" stack sizes for all major OS'es.
Which pretty much proves my point -- since you admit that the _default_ defaults are wrong :-) Otherwise you could surely have let the OS pick "suitable" sizes...
Giving that freedom would in theory be "nice" but I think in practise it really wouldn't help much. Current defaults are about "twice as much as seems to be needed"
Thus halving the maximum number of concurrent threads available. Why not, say, 25% more than seems to be needed? Surely if you waste as much space again as you think is necessary, you don't really have any sort of idea how much is necessary. Why not three times as much, to be doubly additionally safe :-)
I still think it would be handy to be able to start tasks which you know have small stack requirements with small stack sizes -- for example, if you have a bunch of worker tasks which analyse the first N bytes of a file to try to guess its type, without recursive code, like libmagic but smarter; or a bunch of subtasks to relay fixed-size chunks of data to and from a proxy socket in another process. Giving them 8m each seems a little excessive...
Of course on Windows my suggestion is mostly uncontroversial since stacks grow from their initial size automatically if needed. Max stack size is set in the EXE header of the parent thread, and defaults IIRC to all VM. You can lock in a different maximum stack size for individual threads, but [a] only IIRC on versions after Windows 2000 and [b] not via the _beginthreadex() wrapper to CreateThread(), which LuaTask rightly uses.