[770] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: fork() vs send()

daemon@ATHENA.MIT.EDU (Sat Aug 19 13:15:01 1995 )

From: Chuck Adams <cadams@weather.Brockport.EDU>
To: brandon@avon.declab.usu.edu (869683 Gillespie Brandon James)
Date: Sat, 19 Aug 1995 11:08:45 -0600 (MDT)
Cc: coldstuff@MIT.EDU
In-Reply-To: <9508160513.AA15091@avon.declab.usu.edu> from "869683 Gillespie Brandon James" at Aug 15, 95 11:13:04 pm

869683 Gillespie Brandon James drew these hieroglyphs:
> 
> I've been toying with the implementation of fork(), and Jeff brought up that
> it may be better to implement something slightly different, such as:
> 
>     send(object, 'method, [args])
> 
> Which would be virtually the same as object.method(args), except for that
> it "forks" off.
> 
> Anybody have comments on this, compared to a direct fork() implementation?

my vote is for a direct fork implementation.  send() just doesn't hint
at forking.  if you want to get LPmuddish (you may stop laughing now),
you could call it call_out(), but fork is so much more versatile, and
lets you fork off a whole block of code instead of a single method
call.

However, they're actually semi-different concepts anyway.  fork() has
to copy the execution environment, whereas send() wouldn't have to.
So send() would be a lot "cleaner" than using an explicit fork.  Am I
far off the mark here?

Anyway, I suggest two things if you do create it:

1. Call it something different.  send() just doesn't say 'fork'.

2. An argument for a delay time ala fork (n)