[DGD] Re: Couple DGD questions

[Frank Schmidt]

On Thu, 11 Jun 1998, E. Harte wrote:
> I'd like to have confirmation or denial of the last part from Dworkin, as
> most definitely remember there being a difference between using a 'pure'
> kfun in the auto-object and a static function that happened to be defined
> in the auto-object.

Let's wait and hear what he says then. I haven't seen any technical
difference in the uses I have with them, and real kfuns though. Maybe it
is a bug ( I hope not).


> +--- Quoting from doc/Introduction ---
> |    void create()
> |
> |        Called in an object which has just been cloned, or if it is not a
> |        clone, just before a function is called in it for the first time.
> |        The actual name of this function is configurable.
> +---

Nods, already implemented the "fix" in compile_object(), although a little
tricky since I also use compile_object() in call_object(). But recursion
is always funny part of programming, grr ;)


>Functions called from DGD itself may not be private, only static (or no
>additional restrictions at all, of course).  That goes for functions
>called in the driver-object as well as functions called by the call_out()
>kfun.

Ah, duh. My test was with the wrong call_out(). Any way to differentiate
between a private function and static function? I'd like private to not
be called, and static to be called with my own call_out().


>Uhm, no.  But if you replace previous_object() with previous_program()
>then your claim becomes truth.  The problem with previous_object() is 
>that it'll be 0 when the calloutfunction (__heart_beat() or whatever) is
>called directly, without call_other(), from for instance another
>call_out().

Yes, I agree. Previous_program() is best. Also previous_object() is
strangely implemented. E.g. call_other(this_object(), "func"), makes
previous_object() == this_object() :-I Don't remember if this was with
call_other() redefined in auto object, or not, or both.


Stephen Schmidt wrote:
>Does "shut down the system" mean things like forcing all the users
>to quit? Or does it mean that you need to invoke the shutdown()
>kfun from within interrupt()? I'd always assumed that DGD would
>shut down automagically if it got a kill signal, but that seems
>not to be correct. I will Try It And See What Happens, but this
>seems important enough to verify with people more knowledgeable
>than I...

The way I have understood it, interrupt() is called when the driver
receives a process kill under the operating system. But each process
may decide for themselves if they want to be killed or not (with exception
of kill -9). 

I suspect DGD leaves this up to the creator of the driver object, so you
may perform a shutdown(), if that's what you want. Also, saving users,
kicking them off, performing state dumps, etc may be done just before this
shutdown() or inside the function. The net result is that the driver
process will be safe to kill, instead of having to do an unsafe 'kill -9
<pid>', which should kill it no matter what, and it doesn't have time to
shutdown itself safely.


Btw, I think DGD should support exitcodes with shutdown(int exitcode). It
would make scripts able to act on how the driver process got terminated in
a variety of ways.

While I'm at it, it would be nice if stdin/keystroke to the driver process
would call receive_message() in the driver object. It would be the
opposite of send_message() going to stdout. Any comments?


My few cents,

Frank





List config page:  http://list.imaginary.com/mailman/listinfo/dgd