Previously discussed in id:1829466 -- in addition to the changes already made, something akin to a '-startuplimit' parameter for DreamMaker that takes a number 'n'
n < 0: No limit to startup() calls
n = 0: No startup() calls allowed
n > 0: n is the limit of startup() calls
- Is not respected, even if specified, for child processes spawned by startup() -- current behavior applies in that scenario
- Overrides any internal 'sane' default
I could see some merit in wanting this to be configurable at runtime as well, in the case of Windows DD. In Kamuna's case, one may want to maintain a reasonable limit just for safe keeping, but still be able to increase it if need-be. For non-Windows systems, the ideal solution would probably be to set this to unlimited and set restrictions at the ulimit/limit level.
Regardless, this would make the choice explicit for the host while maintaining a reasonable default behavior.</0>
ID:1969593
![]() Oct 19 2015, 9:32 pm
|
|||||||
| |||||||
![]() Oct 20 2015, 2:16 pm
|
|
+1
|
As a parameter I don't see how this would work; a param could be set by startup(), which means any rogue .dmb could override the security feature.
|
Lummox JR wrote:
As a parameter I don't see how this would work; a param could be set by startup(), which means any rogue .dmb could override the security feature. ? The process that results from the startup() call would use an n=0 limit as you mentioned that it currently does in your initial response to id:1829466 -- this parameter would effectively be ignored in the case that it's a child world. |