🚀 go-pugleaf

In article <DEVEN.89Mar9113018@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>Distribution: comp
>?

	That's what Pnews gave me as a default.

>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.

>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).

>Speaking of Execute(), I have a gripe with it.  V1.3 Execute() does
>NOT use run if it is in the DOS Resident list, but still insists to
>run c:run...  which is a BIG pain if the system disk isn't in the
>drive.  (assigning c: to ram:c or rad:c isn't much help; then you
>can't be asked for the system disk back to run programs in sys:c which
>aren't resident...)

	Known.

>Say, if I replaced that Command Dir lock that's in the CLI structure
>for that one CLI process, would it look there without having to
>assign c: elsewhere?

	You believed the name of the field, didn't you?  Poor naive boy. :-)
It's really the BPTR to the path list.

>>	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.

>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]
>That's fine by me.  (expected to do so anyhow.)  What state do those
>functions run in?  Supervisor or User mode?  Can they be interrupted
>by the timer clock, and end up with Exec trying to switch out when it
>already was?  Or, will they not be interrupted?  (i.e. if those
>functions took 10 seconds to execute, would it break anything other
>than system performance?)

	I suspect in supervisor, non-interruptable (by the switcher, interrupts
will still occur, I suspect).  Taking 10 seconds would be very, very bad in
a real-time OS.  Even VMS doesn't take 10 seconds to switch! :-)  For more
data, ask bryce@cbmvax (I haven't played with it).

>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.

>No way to dup a filehandle?  Why couldn't two programs use the same
>filehandle?  Can two non-BCPL programs share a file handle?  It is
>lack of mutual exclusion or something else?

	Two non-BCPL programs can right now.  BCPL programs use the buffering
fields in the file-handle, and would clash over them.

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