[810] in Coldmud discussion meeting
(forward) Re: Multithreaded ColdC...
daemon@ATHENA.MIT.EDU (Sun Sep 17 17:02:05 1995
)
From: brandon@smithfield.declab.usu.edu
Date: Sun, 17 Sep 1995 14:55:56 -0600
To: coldstuff@pippin.ece.usu.edu
Sorry for the delay, I was supposed to forward this a while ago...
------- Forwarded Message
From: paul@llama.net (Paul Kautz)
Subject: Re: Multithreaded ColdC...
Date: Sun, 10 Sep 1995 08:10:43 -0700 (PDT)
Content-Type: text
Content-Length: 1505
Status: RO
> Synchronization is the act of a thread gaining absolute control of an
> object. Only one thread can be synchronized with an object at any given
> time. There are two ways of synchronizing with an object. First, one
> can implicitly synchronize the method with an object by adding the
> synchronized method flag. Or, the block control 'sync' can be used,
> which accepts a list of objects and contains a block of code to execute
> while synchronized to the object(s), such as:
>
> sync (this()) {
> while (times) {
> .call_synced_method();
> times = times - 1;
> }
> }
How would the permissions be set up? Making it a `system' statement
would seem to defeat the purpose, and the great thing about cold
perms is that they're entirely in-db other than that. Would a particular
query method be required?
> fork() splits a thread. When called it splits the thread into two exact
> frames. The function fork() has a logical expression value of 0 to the
> child process, and the value is the forked thread id for the parent
> thread.
This seems rather silly. I don't think the original C would have done
this is they had the keen object-oriented environment we have. Either
give fork an argument of a method to look for, or give it a block of
code to execute. Having to continue the method with if/else etc is
awkward and unnecessary, only useful if you want to have your entire
program as one linear `file'.
Remember our advantages over a unix environment.
Paul Kautz
------- End of Forwarded Message