Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Is there a limit...to the number of tasks in ISIS?
Message-ID: <34162@cornell.UUCP>
Date: 13 Nov 89 14:14:52 GMT
References: <34156@cornell.UUCP>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 24

In article <34156@cornell.UUCP> rcbc@honir.cs.cornell.edu (Robert Cooper) writes:
>There is no intrinsic limit to the number of simultaneous lightweight tasks
>in an ISIS program. However you will eventually run out of virtual memory.
>

Just to follow through on this thought, in our own code we always
avoid creating large numbers of tasks.  The virtual memory thrashing that
starts to occur after around 30-40 tasks is just not worth the simplicity
such a solution yields, and even under a system like Mach (which has a better
pager) large numbers of tasks still cost too much to tolerate.

I almost always find that there is a way to solve this type of problem
by packing multiple messages into a single bigger one (the message analogy
to "buffered output").  See clib/cl_join.c for example: xfer_out() does this.

Another approach is to use _non_blocking_ tasks to receive the incoming
messages.  Since they don't block, you are conceptually using a large 
number of tasks, but at any point in time only one will be active.

(Warning: if a task DOES block, keep in mind that almost anything can
happen while it is sleeping: processes can fail, etc...)  Tasks block by
(1) doing ISIS system calls, or (2) by calling t_wait().

Ken