Jan Friesse

My 2cents. Looks like a extremely overengineered solution. Ability to reopen log seems like a viable feature and it's just good enough solution.

But this (`g_hash_table_new_full`) is what is currently implemented in libqb (the `QB_MAP_NOTIFY_FREE` callback). Without this callback libqb behaves like `g_hash_table_new`. Sadly without callback it's not possible to safely delete item...

Yup, such comment would be useful. Also we may add something like `g_hash_table_new_full` which would add callback - that would make a job of clarity. And honestly I'm not so...

I have one question (before trying to find it in rust/glib docs). In corosync we use prefix callbacks (`ICMAP_TRACK_PREFIX` which is converted to libqb `QB_MAP_NOTIFY_RECURSIVE`) intensively (historically reason is objdb...

> > I have one question (before trying to find it in rust/glib docs). > > In corosync we use prefix callbacks (`ICMAP_TRACK_PREFIX` which is converted to libqb `QB_MAP_NOTIFY_RECURSIVE`) intensively...

API looks sane, but what is the use case? Also I was unable to understand following part: > btw. this looks exactly like a sequence every forking daemon > utilizing...

> On 27/09/18 00:18 -0700, Jan Friesse wrote: If it is about daemonization process, then why should daemon do the exec after fork? > In case it's a hierarchical daemon...

Ok, now it makes a little more sense. I have doubts about the solution really solves any real problem (especially when daemon is systemd enabled and notifies its state), but...

@asalkeld : Yes, it's expected to be ether extra call (like dispatch_in_place) where it will return ENOSUP on not supported ipc methods and developer must take care to call standard...

Perfect. I think it would be much safer and reliable to call function(s) instead of `system`/`popen`.