Re: LuaTask and memory allocation
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: LuaTask and memory allocation
- From: Duck <duck@...>
- Date: 2007年6月28日 08:25:03 +1000 (EST)
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.