[14:05] <sadmac> Keybuk: how was your flight?
[14:49] <Keybuk> sadmac: short and uneventful
[14:49] <Keybuk> just the way I like them ;)
[14:49] <sadmac> Keybuk: sweet
[14:49] <sadmac> Keybuk: so after hacking n-ary event operators together, I'm getting a segfault inside nih_ref
[14:50] <sadmac> Keybuk: specifically in a call to nih_list_add_after
[14:51] <Keybuk> is the pointer freed?
[14:52] <sadmac> Keybuk: I don't believe so. If so its an error outside my code.
[14:52] <sadmac> or maybe not... yeah it could be in the parse_job changes
[14:55] <Keybuk> one of the obvious issues with nih_alloc
[14:55] <Keybuk>  x = nih_alloc (NULL, ...)
[14:56] <Keybuk>  nih_ref (y, x)
[14:56] <Keybuk>  nih_unref (y, x)
[14:56] <Keybuk>  // x is now free
[14:56] <sadmac> Keybuk: it also bugs me that you have to declare nih_local in a certain place or you get a leak
[14:57] <sadmac> nih_local int *foo; while {} vs while {nih_local int *foo }
[14:58] <sadmac> Keybuk: I have a solution for that. I would propose a macro that would create a local /parent/ rather than a local object. So when you did locally scoped allocations, you'd just give them that parent and they'd all go away at once.
[14:58] <sadmac> its a bit harder to screw up, and its not mutually exclusive with nih_local so we can keep bot.
[14:58] <sadmac> *both
[15:01] <Keybuk> not sure I follow
[15:01] <sadmac> Keybuk: so where you had this:
[15:02] <sadmac> nih_local obj *foo = nih_alloc (null, sizeof obj);
[15:02] <sadmac> Keybuk: you'd have this
[15:02] <Keybuk> yes, you can do that ;)
[15:02] <sadmac> NIH_DECLARE_LOCAL_ANCHOR (anchor)
[15:02] <Keybuk> nih_local void *foo = nih_alloc (NULL, 0);
[15:03] <sadmac> obj *foo = nih_alloc (anchor, sizeof obj);
[15:03] <sadmac> Keybuk: nih_alloc doesn't assert there?
[15:03] <sadmac> Keybuk: because otherwise yes, that'd pretty much be it
[15:04] <sadmac> Keybuk: though I'd recommend the type be struct dummy * so it screams a bit if you try to use it as an object.
[15:10] <Keybuk> not that I know of
[15:11] <sadmac> Keybuk: well that works out nicely then
[15:14] <Keybuk> though I don't see that that helps you
[15:17] <sadmac> Keybuk: it makes it a bit harder to lose objects
[15:18] <sadmac> Keybuk: anything that has that as a parent at the end of the function /will/ get an unref
[15:18] <sadmac> Keybuk: regardless of whether its address is stored at a particular local pointer.
[15:21] <sadmac> Keybuk: it also offers a performance advantage
[15:21] <sadmac> NIH_DECLARE_LOCAL_ANCHOR (anchor)
[15:21] <sadmac> while (...) { /* use anchor for allocating */ }
[15:22] <sadmac> return;
[15:22] <sadmac> the stuff the loop created isn't freed til return. The loop now never passes through allocation code. The program gets faster.
[15:23] <sadmac> *never passes through free code
[15:25] <Keybuk> why is that different than the alternative?
[15:25] <Keybuk> the loop can instead consume large amounts of memory
[15:27] <sadmac> Keybuk: unlikely for most use patterns. Deferring garbage collection should be a big win in 99.9% of cases. The other way is still there. Furthermore, the old C maxim that variable declarations belong at the top of the function (and that's not a crazy assertion whether you agree or not) is no longer punished with a memory leak.
[15:28] <sadmac> Keybuk: and what's more, you no longer treat objects specially based on what variables they're held in. Less semantic confusion
[15:29] <Keybuk> but why can't you put them in the while loop?
[15:30] <sadmac> Keybuk: you can, its just gross.
[15:32] <Keybuk> sure
[15:32] <Keybuk> which is why I tend to attach them to something else outside it
[15:37] <sadmac> not following
[15:37] <Keybuk> well, I do what you do in those situations
[15:38] <Keybuk> have something at the top-level of the function and attach things to it
[15:38] <sadmac> makes sense
[19:10] <Milan-BV> Keybuk: hi!