On Thu, 14 Feb 2008 22:09:04 -0000, Pietro Gagliardi <[EMAIL PROTECTED]>
wrote:
Here's what I think is the best solution: statically allocate the
maximum number of tasks per process:
struct JobControlBlock { /* the name my OS uses for the info field of a
process (job) */
Task *mainTask; /* task == thread */
Task *jobTasks[400]; /* pointers to entry in an array of statically
allocated tasks */
};
A Task runs a function; it does not continue executing at the current
point. Returning from that function halts the task. Returning from the
main task halts all tasks.
That parallels Microsoft NT's concept of threads (aka, lightweight
processes):
//ThreadProc is the "function" the thread runs
hThread = CreateThread (&security_attributes, dwStackSize, ThreadProc,
pParam, dwFlags, &idThread);
Which is rather old, by the way. The same concept re-surfaced later on in
.NET as the Thread and ThreadPool classes in System.Threading namespace.
Sidenote: despite the negative hype, Windows programming is jolly merry.
Now a SpawnTask() (fork()) can only be done to create up to 400 tasks
with the exception of the main task.
As Erik Quanstrom pointed out, setting a limit for the total number of
processes/tasks/threads would create another vulnerability. That is,
inability to create any more processes because some
malicious/poorly-written process is consuming all the quota.
I am wondering which magical property of the number 400 has made it
suitable as the limit to the number of tasks. Four hundred tasks may be
amenable on your platform but wreak havoc on somebody else's poor old PC.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
