[770] in Coldmud discussion meeting
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)