[DGD] Is Running Atomically.

[Gary]

On 24/09/16 22:19, bart at wotf.org wrote:
[snip]
> But you can write something like this which will work regardless of what lib
> you use:
> 
> string error;
> 
> error = catch( write_file(....) );
> if( error ) {
>    do something useful, you now have the original message and the error
> (without trace)
> }
> 
> The error you get from a write_file in atomic code is pretty explicit :-)

I think I'm going to stick with using the running_atomically() check for
now as it limits the amount of error output logged to the console.

By that I mean, if a compilation error occurs stderr will have a log
entry for compilation failing on line xxx as well as a runtime_error,
the trace of which is also logged.

Both those log entries would attempt a write_file which would be caught
and redirected to stderr, however that would also cause two
atomic_errors the traces of which will be output to stderr.

It's a minor issue, but I'd prefer to avoid the extra stderr spam where
possible.

The running_atomically() test ensures stderr only sees the compilation
failed on line xxx as well as the runtime stack trace. write_file will
only come into it logs if it fails for a different reason.


Longer term I do want atomic errors to end up in the log file. So I'll
eventually look at implementing your idea of logging to a buffer which
can then be written out after atomic has rolled back everything
(assuming steps are taken to preserve the buffer content during the roll
back).

On 24/09/16 22:31, Felix A. Croes wrote:
> While it can be done with a kfun, there are numerous ways to detect
> this in LPC.
>

For what it's worth, I did try two methods of detecting if code was
executing atomically.

The catch wrapping method bart mentioned, which works but generates a
little extra console spam that I'd prefer to avoid.

The other method was one I found in the email archive, regarding doing a
status()[ST_TICKS] - status()[ST_TICKS] and seeing if it was running at
the x2 tick rate that atomic causes.

Since that's based on ticks remaining however, there were times when it
evaluated to 0. I think that's when rlimits was disabled during
compilation, so this method was not reliable enough.

If there are any further ways to detect atomic via LPC please let me
know. Until then, the extra kfun appears to do the job well enough that
I can move onto other areas of the mudlib. If I end up keeping that
longer term, I'll look at moving it to an extension.

Regards,

Gary