🚀 go-pugleaf

In article <6237@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>In article <DEVEN.89Mar9113018@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>>In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
 
>>A big problem with CLI processes is that they are (quite arbitrarily)
>>limited to 20.  That is too few; I want to implement concurrent pipes
>>and simple backgrounding, and I don't want to have them all as CLI
>>processes.
 
>	Agreed, it is too few.  This may change.
 
What about setting the CLI proc number to 0?  Will some cli things choke on
this?  Lattice's forkv() uses proc number 0. (What do workbench programs do?)

>>Of course, the only real way to break from the BCPL crap is to rewrite
>>the file system, or at least the interface to it.  I wouldn't mind
>>doing so, and have considered it a number of times, but don't have the
>>time to do so just yet.  Maybe in a couple months.
>
>	(suppressed giggle) it ain't as easy as it looks.  Just ask Steve
>Beats (Mr FFS).
Let me know how you want to eliminate the BCPL stuff.  I plan on writing a ROOT:
to allow other filesystems to be mounted onto it.  It would be a great place to
eliminate some BCPL garbage (or at least hide it from those that are in the
know).
 
[stuff about braindead Execute() deleted]
 
[stuff about tc_CommandDir deleted]

>>>	I advise against modifying binaries.  Use one of the user
>>>protection bits.
>>
>>Not such a good system.  user protection bits are all too easily lost.
>>I'd much rather have the binary identifiable.  The idea I had to
>>identify it which seems most workable is to have a special startup
>>module which begins with a branch past a magic number (longword) which
>>the shell's loader could check against.  Sound reasonable?
 
>	I've seen it done.  Check the arp programmers docs.

Please use the magic number.  I think using the file protection bits is a BIG
kludge.  If we go ahead and implement magic numbers, programs that depend on
the MMU for different memory setups, etc. can be identified and dealt with
accordingly.  For instance programs that are very time sensitive can be labled
with a noswap attribute (are you happy Peter? :-).  And things that depend on
having an 881 around can be identified at load time and the user can be informed
about the problem instead of having the machine go through an F-line trap or
whatever. (this can go on to include 020's and 030's...040's 050's :-)
 
>>Yes, when I looked into it, I decided that it would be better
>>implemented on top of Exec and such.  However, there are some
>>low-level changes that would be valuable, like sending a signal to a
>>process when it goofs up, instead of GURUing and bringing down the
>>entire system...
 
>	You can trap Alert().  Of course, code that dead-ends may not
>deal well with Alert() returning....
 
>[tc_Launch & tc_Switch]
back to the question about having fork() and exec() included as a linked library
or as a runtime library.  Well, to put my two cents in, i think that it should
be a runtime library so that your code can depend on it being there (sorta...)
and so that your task does not have to include all of his extra code.  I like
the idea of an init proc.  You could send a message to init's port (internal to
fork) and wait for a reply.  Init would copy the proc and send a message to the
parent and to the child with the respective returns for each.  If i'm not
mistaken there is a field in the Task structure that contains the pc.  Init
could use this to set the child up executing at the same place (offsets would
of course have to be calculated).

>>How about using the tc_UserData field to point to an extended
>>structure?  Is it used for anything?  Or maybe using the name filed in
>>the task's node structure as an extended structure pointer?  Or are
>>both these out, too?
>
>	Applications are allowed to use it.  The ln_Name points to a real
>task name.

According to John Toebes, he uses tc_UserData for something in lc.lib.  If I
rember correctly, he uses it for forkv() and forkl().  I asked him about it
because i was going to use it to store env variables.  Oh well...

[problems with BCPL programs using the same file handles deleted (please
 answer the question though)]

>-- 
>Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup


						rsb

ps  I am NOT responsible for my spelchecker's errers.
--
-- 
rsb@dukeac.ac.duke.edu		///	"Amigas do it with hardware."-- Me
rutgers!mcnc!ecsvax!dukeac!rsb ///     "Sycamore is open."-- Negativ Land
I'm a HORSE, of course.    \\\///     "I luv S&M!!!"   "No geeks here!!"
Disclaimer NOT included!    \XX/     "This space for rent"