🚀 go-pugleaf

In article <C0JquI.6K7@CAM.ORG> vandry@CAM.ORG (Phillip Vandry) writes:
>This thread was in EMail, but I believe it is more apropriate for it to
>be in this group.
>
>> >instance of the program again (well, I guess you could if you really
>> >worked hard on your program, but it's not worth it, is it?)
>> 
>> It is *definitely* worth it. Just think of 10 users using vi. Now would
>> you want 10 copies of vi in memory or 1 copy of vi with 10 dp/stack
>> segments for each instance of the program?
>
>But I'm not sur eit can be done. It involves keeping no variables in
>the program itself, and therefore using pretty big chunks of bank 0
>memory. But even then there are still GS/OS parameter blocks which
>pretty much must reside inside the program. There would have to be
>semaphores around all accesses to GS/OS paramter blocks, and since
>each instance of the program is seperate, who creates the semaphores
>and tells everyone else about them?..
>
>> Albert
>
>| Phillip Vandry | Vandry@Cam.Org | II the future! | II 1993!          |

It *can* be done. You don't need to use big chunks of bank 0 memory. All
it requires is *good* use of bank 0 memory. You would have to use semaphores,
but gsh and the kernel use them now.

Who creates the semaphores? I think what you want to say is how can one
program keep another from using global data (GS/OS parameter block) and
guarantee that it be done. I had some sample code for this but it escapes
me right now. All you have to do is keep a counter that is decremented
by program one. The next instructions checks for a certain value of this
counter. Because one program is *guaranteed* to decrement this counter,
every other program will fail the test after the decrement. Why? Well
remember that the processor status flags will be preserved between
switching. So, if this decrement gets executed then another program
jumps in and decrements the counter, the next instruction (say BNE)
will fail and when execution returns to the original program that
decremented the counter the compare instruction will pass. So, only
that program modifies any global data.

You could also turn off interrupts while modifying global data. This is
not good though.

The benefits of reentrant programs (especially on the GS with limited
memory) is worth the effort it takes to make your program reentrant.
If a multiuser BBS system gets created for GNO, then the need for
reentrant software is more important.

Albert