[521] in Coldmud discussion meeting
Re: To-Do list..
daemon@ATHENA.MIT.EDU (Sat Nov 5 00:19:56 1994
)
Date: Sat, 5 Nov 1994 00:17:48 -0500 (EST)
From: James C Deikun <jcdst10+@pitt.edu>
To: Alex Stewart <riche@crl.com>
Cc: coldstuff@MIT.EDU
In-Reply-To: <199411042101.AA00504@crl4.crl.com>
> Atomic code blocks
> This is really needed now that we have suspend capability, and I will
> probably implement it as an 'atomic <statement>' syntax, i.e:
> atomic object.some_special_method();
> and
> atomic {
> do this;
> and this;
> and this too;
> }
> and etc.. If an attempt is made to suspend or pause while executing in an
> atomic state, an error will be thrown instead.
It seems to me this construct isn't sufficiently general to amount
to much. It won't be worth the bytes it takes in the server in a
multithreaded environment (it'd hold up *way* more tasks than
necessary if it could even be implemented successfully at all,
which is doubtful), and it doesn't allow for things like saving
your state and proceeding to do the suspension--it's an all or
nothing thing. To me this is the major problem of the ColdMUD
error handling system, which got fleshed out for me in a
discussion of similar issues a while back in moo-cows. It's based
on LISP catch/throw, which was never really meant for error
handling as such. Without resumes, it's way too static, and it
doesn't really support good stack unwinding right now either.
These are more basic issues you need to be working on.
> Callback system
> The DB will be able to call request_callback() to instruct the server to
> call $sys.callback at the next appropriate task opportunity. Multiple
> requests will result in multiple callbacks. I'm not sure whether pause()
> should be kept or not once this is implemented, as its functionality can be
> performed with this and suspend()/resume().. I'll have to run some tests to
> see if there's a significant speed advantage of pause() over the other way
> of doing things..
What does this actually involve? (Besides a really long awkward method
named $sys.callback of course :)
> Syntax/builtin changes:
>
> with handler => handler
Should become irrelevant.
> del_name('dbref) => del_dbref('dbref, #object)
Does this mean there can be more than one object to a dbref? If
it is, I can't see how this would cause anything but confusion.
If not, why the extra argument?
> bind() => bind_port()
> unbind() => unbind_port()
Personally I'd prefer to see
bind() => listen(port, object)
unbind() => unlisten_port(port)
unlisten_object(port)
unlisten(port, object)
listeners(port)
listened_ports(object)
Port isn't necessarily a TCP port; just something the server can
sensibly listen to. Could be an identifier for a modem, among
other things. The other parameters would be likewise genericised.
(Hey, it makes as much sense as genericising strings.)
> conn_object.failed() => .connection_failed('refused/'timedout, "addr",
> port, socket)
Are you sure this shouldn't be an error rather than a callback? After
all, this never happens anyplace an error would not be sensible. I
could see a case for this back when the server couldn't queue tasks,
but not now.
> conn_object.parse() => .connection_received(`[buffer])
Shouldn't this maybe just be .receive()?
> set_heartbeat_freq() => set_heartbeat()
How about set_heartbeat_interval()? Long, but it is after all what
the thing actually does, unlike either of the above designations.
> Flexible builtin bindings
MOO and ColdMUD get more alike all the time. It'll be interesting
when/if CoolMUD gets in on this trend...
> Other contents/directories are allowed but ignored by the server.
> Logfile output will also be changed to go to stdout instead of stderr.
> stderr will be reserved for actual error messages.
This wouldn't work well with something like MOO's NP_SINGLE network
module.
> Up for Discussion
> -----------------
> Do-while syntax
I've always liked this one. Lots of languages could benefit from this
(C, C++, Pascal, etc). It'd certainly save on a *lot* of convoluted
constructs (if-thens with first-time flags, duplicated code, and on
and on...).
> I'm still kinda unsure about this, really.. the idea with the above plan is
> mainly to try to keep connections of all sorts (network connections, pipe
> connections, etc) all as similar as possible for consistency of interface,
> but that means things like .connection_opened has to get different args
> depending on the connection type and you need to use two separate objects
> for handling sdout and stderr separately.. An alternative would be to have
> a different interface for pipes to other processes, along the lines of
> .pipe_opened, .pipe_closed, .pipe_stdout, .pipe_stderr, etc..
>
> Anyway, what do people think?
I think it's a great idea and should be extended to things like in-DB
streams. That'd take a little more reworking, though; echo() simply
does not generalise well to this.
> Change the task timeout system
> The main question is just how should it be changed. method-local tick
> counts clearly are not sufficient. It could simply be changed along the
> same lines as MOO's task-timeout handling (tick counts relative to the
> entire task, and renewed when the task suspends).. what I'm thinking about
> at the moment is changing tickout checking to be based on the task rather
> than the method and allowing it to be set for any given task with a builtin
> (this would make things more flexible than a standard tick-limit imposed by
> the server, though it would mean things like pause() would have to go
> through thunks if the tick count was to be renewed..) Should task timeouts
> be based on ticks, seconds, or both? (maybe seconds would be better overall,
> since a tick is really such an arbitrary thing anyway)
Ticks have their uses. Stopping tight, fast, useless infinite loops
earlier strikes me as a good example.
I'd say use both ticks and seconds. I'd also say make server defaults
for various instances, but let $sys grant extra ticks or take some
away (granting should be used *very* sparingly).
> buffer_to_strings() => ascii_buffer_to_strings()
> strings_to_buffer() => strings_to_ascii_buffer()
>
> I also believe that the string dataype should simply be defined as a series
> of "text characters", where what exactly a "text character" is and how it's
> represented internally are nobody's business as long as it can represent all
> the printing characters one needs, whereas a buffer should be defined
The minimum here would be us-ascii characters, since everything in the
server is expressed in terms of them, as well as all the internals of
all current cores. Strings should also IMHO never include newlines or
vertical tabs/formfeeds (or the system-local equivalents of such).
> explicitly as a series of 8-bit bytes, with no particular significance to
> what they represent. I.e. the definition of a string is based entirely on
> what it's used for and not what it is, and the definition of a buffer is
> defined entirely on what it is and not what it's used for.
I'm not sure buffers should be nailed down as '8-bit bytes'.
Unicode-supporting systems should perhaps get 16. I'm not entirely
certain of this, either.
> "locked" compilation flag for nethods
> A compilation flag (like disallow_overrides) which would indicate that the
> specified method cannot be changed from inside the running server (it must
> be modified offline), for security. Basically, does anybody have any reason
> I shouldn't go ahead and implement this? (sounds good to me)
This one is IMNSHO entirely silly, superfluous, and otherwise not a
Good Thing(TM). The idea behind it seems to be that by allowing
online changing of methods basic to security one is undermining
security. However, if these methods cannot protect *themselves*
from *unauthorized* changes I'd have pretty graves doubts about
their general security myself. The marginal security gain is simply
not worth making a whole bunch of people crawl on their knees
through textdumps when maintenance needs to be done. The first
thing I'd do if I found this bet set anywhere in a core DB would be
to use a perl script to take all instances out.
--
James Deikun (James@JHM, James & Splat@BlueMOOn)