[DGD] Fatal error when no user object returned

Dread Quixadhal quixadhal at gmail.com
Wed Jun 6 06:55:48 CEST 2018


The only one I can really think of is that of an LPC web server.

If I were working on a web server object and somehow screwed it up so the expected callback function were no longer there (IE: a typo or bad search/replace), it is unfortunate for an incoming connection on that port to shut down the entire driver, if that is indeed what happens.

I’m talking about the object compiling properly, but not being able to handle the driver apply.

Of course, the driver can’t really know if any given connection is essential (like the login object), or something not really required (like a web server)… but I’m inclined to think it should only really be fatal during bootup, and not when it’s the result of an object update.  After all, if you screw up the login object and can’t log back in, you can always send SIGINT to the driver to force it to shutdown (or kill -9 if you really want it dead right now).

Either way, whether it kills itself, or you kill it, you’re going to have to dig up an older state dump to recover and lose whatever progress happened since then… assuming you’re using persistence, of course.

It’s not a huge issue, but it seems like it makes the assumption that every listening connection is VITAL to the system’s operation.

That’s my two cents, take it for whatever it’s worth. 😊

Sent from Mail for Windows 10

From: Felix A. Croes
Sent: Tuesday, June 5, 2018 21:31
To: dgd at dworkin.nl
Subject: Re: [DGD] Fatal error when no user object returned

Dread Quixadhal <quixadhal at gmail.com> wrote:

>[...]
> If, on the other hand, you are trying to attract non-programmers to the genre and give them a platform to experiment on, a certain amount of leniency is probably appropriate.

The genre's problem is that the non-programmers have been attracted, but
the programmers have left.  Hence, stagnation.

As to the issue at hand, I have not seen an argument advanced which persuades
me that the behaviour of DGD should change.

Regards,
Felix Croes
____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd




More information about the DGD mailing list