[DGD] Is Running Atomically.

[bart at wotf.org]

This can actually be done in lpc without modifying the driver, through it
might mean modifying the kernel. The 'trick' is to cause an error, catch it,
and let your error handler tell you if the error was atomic or not. I wrapped
that in a nice afun (test_atomic()) and added a TLS variable which gets set by
the error handler whenever a (caught) error in atomic code occurs.

What I did to solve the 'write_file from logging during atomic code' is to
always append log data to a buffer, and have a separate handler that is
guaranteed to run on its own and outside atomic code that writes the data to
the actual file (with the added advantage that you can spread the writes over
multiple call_outs if there is a lot to write). 

There is a call_out taking care of calling that code, if the logger sees the
call_out isn't running when a message gets logged, it starts the call_out and
appends the data to the buffer, if its already running, it just appends the
data. This keeps ordering of writes correct, doesn't cause a gazillion
call_outs, and its no longer relevant if the logger is called from atomic
code. Of course I modified this later to also be able to log to an lpcdb
database (which is my default log target now) which doesn't need to write
files. That however is not appropriate for some logs which you might want to
look at when the system fails in a way that you cannot access that data.

One note (but that applies unless you specifically take care of it using the
atomic_error function in the driver object, see for example Felix' Cloudlib or
Gurbalib, specifically look at the add/get_atomic_message afuns), if your
atomic function has an uncaught runtime error, everything it did (and was done
by functions called by it) will be undone, hence it will not log anything. As
said, you can work around that using the atomic_error function in the driver
object. Things you write to dgd's tty (so.. using send_message in the driver
object) will show even when the atomic code gets rolled back.

Note that what I do for logging may not be very efficient when running on
Hydra, you may need a second call_out to append the data to the buffer to
prevent undue rollbacks due to accessing the same buffer, in that case, using
a mapping for your buffer, and a timestap as index on that buffer will help
keep the write order correct. Writing to the same file from random threads on
Hydra could be a problem anyway, even when not using a solution like the one I
suggested.

WHile it doesn't answer your original questions about the dgd source, it may
well get you a solution that doesn't require changing the driver.

Bart.

On Sat, 24 Sep 2016 18:18:05 +0100, Gary wrote
> I had the need to determine if a piece of code (within my logd) was
> running as part of an atomic call chain so that write_file calls 
> could be avoided.
> 
> I've added a kfun to extra.cpp as follows
> 
> ----
> 
> # ifdef FUNCDEF
> FUNCDEF("running_atomically", kf_running_atomically,
> pt_running_atomically, 0)
> # else
> char pt_running_atomically[] = { C_STATIC, 0, 0, 0, 6, T_INT };
> 
> /*
>  * NAME:	kfun->running_atomically()
>  * DESCRIPTION:	returns whether the caller is executing within an atomic
> frame
>  */
> int kf_running_atomically(Frame *f, int n, kfunc *kf)
> {
>     UNREFERENCED_PARAMETER(n);
>     UNREFERENCED_PARAMETER(kf);
> 
>     PUSH_INTVAL(f, (f->level != 0));
> 
>     return 0;
> }
> # endif
> 
> ----
> 
> Whilst this appears to work correctly, I've a couple of questions as
> I've not really looked into the dgd source all that much yet.
> 
> Is C_STATIC correct? What is this param for? I noticed there's also
> C_PRIVATE, C_ATOMIC, C_MASK... which can be or'd into the mask, does
> this define what the LPC prototype would be for any auto object override
> of the kfun or serve another purpose?
> 
> The first 0 appears to be number of passed in arguments to the kfun, 
> in this case 0. What are the 2nd and 3rd 0s for? What is the 6 for?
> 
> Is there any documentation that provides any a rough overview as to the
> internals of DGD? I'm guessing not and it's just a case of diving in 
> and tracing through, but figured it was worth asking.
> 
> Also, is this of any general use to others and would it really be better
> off as an lpc extension?
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/