🚀 go-pugleaf

In article <632@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes:
>In article <413@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes:
>>One approach that seems reasonable would be to send a message to the 
>>timer.device asking it to send you a message in ten minutes (600 secs).
>   Hmm, we have a very nice OS here with a shared address space and 
>named blocks of memory and lightweight tasks and ....
>   we are still thinking in terms of Unix.
>
>How about (let's be gross now)
>run your compute process. Have it write the adress of the 
>data to a file called "data". Then run another process
>that counts down ten minutes, opens the file to get the 
>address, looks at the data, and prints out information about it.
>Alright, less gross:
>Your program spawns another program with the arguments that 
>tell it where to look and how often and what to print. That 
>second program opens a window to talk to you.
>Or, maybe:
>Spawn a lightweight process (task is such a better word, 
>but Mach kinda changed the meaning). Since it shares your 
>context it *knows* where to look and how often to print.

Somebody forgot their Operating Systems course, eh?

The problem with all of these approaches, of course, is that you've
got two processes reading the same data at the same time, or, more
specifically, one reading the data while the other is still writing.

Naturally, you could use semaphores or some other sort of locks to
make sure that this doesn't happen, but that would be a rather silly
solution since the processes would never execute concurrently.  Any
solution that requires two processes is a kludge at best because of
the locking/concurrency problem, unless you could guarantee that the
data can be divided into chunks that are mutually exclusive so that
you could guarantee valid data (actually I guess that you only need to
guarantee that the transactions are serializable).

Plus, if you use software interrupts your code has a better chance to
work under the 1.4 vm (yes, folks, it's that time [to think about the
next os]).


>ron


-- 
Morgan Jones                                 morgan@hcr.UUCP
Human Computing Resources, Toronto, Canada
"BMATH - 8 months and counting ..."