| === robbiew is now known as robbiew-afk | ||
| sadmac | Keybuk: thought: nih_discard should run the destructor always. | 05:07 |
|---|---|---|
| Keybuk | sadmac: why? | 09:39 |
| sadmac2 | Keybuk: Think of it in the case of our most common destructor: removing the node from a list. Discard should only leave the item around for people still referencing it, which means external references like that should go away. | 14:17 |
| === robbiew-afk is now known as robbiew | ||
| Keybuk | right, but that's not how it's supposed to work ;-) | 14:37 |
| Keybuk | discard is "drop the NULL reference" | 14:37 |
| Keybuk | the assumption is that you allocate an object with a NULL reference, pass it to something that actually references it | 14:38 |
| Keybuk | and then drop the NULL ref | 14:38 |
| Keybuk | if it didn't get referenced, dropping the NULL ref does free it | 14:38 |
| Keybuk | e.g. | 14:38 |
| Keybuk | void *foo; | 14:38 |
| Keybuk | foo = nih_new (NULL, SomeObject); | 14:38 |
| Keybuk | nih_list_init (&foo->entry); | 14:39 |
| Keybuk | pass_to_some_func (foo); | 14:39 |
| Keybuk | nih_discard (foo); | 14:39 |
| Keybuk | ... | 14:39 |
| Keybuk | where | 14:39 |
| Keybuk | pass_to_some_func (void *foo) | 14:39 |
| Keybuk | { | 14:39 |
| Keybuk | nih_list_add (&foos, &foo->entry); | 14:39 |
| Keybuk | nih_ref (foo, &foos); | 14:39 |
| Keybuk | } | 14:39 |
| sadmac2 | well that's what it /does/ sure :) The name to me implies "normal operation of the program is done with this object. Only keep it around if something hasn't remembered to dereference it yet." | 14:41 |
| sadmac2 | In a more literal sense, "discarding" the object should take it out of a list. | 14:42 |
| Keybuk | it's more equivalent to g_ref_sink in the old libgtk style referencing | 14:42 |
| sadmac2 | Keybuk: also I've occasionally found a list that I'd prefer used internal referencing (i.e. actually do nih_ref (list, list->next) etc rather than just having a destructor pull it out when its done). I was thinking of adding a second set of list helpers to facilitate maintaining a list in this way. | 14:44 |
| Keybuk | sure, that's more like how nih_list_entry works, no? | 14:45 |
| sadmac2 | hm? | 14:45 |
| * sadmac2 pulls a libnih tree onto his work machine | 14:45 | |
| Keybuk | NihList is embedded in structures | 14:47 |
| Keybuk | NihListEntry is an NihList with a generic pointer | 14:47 |
| Keybuk | where the list references the data contained in it | 14:47 |
| sadmac2 | oic. that's an interesting way of doing it... | 14:48 |
| sadmac2 | does its destructor unreference its target pointer then? | 14:48 |
| Keybuk | you could make it do that | 14:48 |
| sadmac2 | then you could just use nih_free on the entry to remove from the list | 14:50 |
| Keybuk | in theory the list/alloc stuff should be flexible enough to do it either way | 14:50 |
| Keybuk | one of my other two libnih-using projects doesn't use the embedded list stuff | 14:51 |
| Keybuk | because every object is in multiple lists | 14:51 |
| sadmac2 | I've also had some ideas I'm sitting on about how to reduce nih_alloc's overhead and possibly make it a bit more flexible, but I'm still churning. | 14:52 |
| sadmac2 | I have a thought that we could kill the parent/child lists and store a big adjacency matrix instead within a good sparse matrix data structure | 14:56 |
| sadmac2 | might perform better too (cache lines hate linked lists) | 14:57 |
| === robbiew is now known as robbiew-afk | ||
| === robbiew-afk is now known as robbiew | ||
| === notting_ is now known as notting | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!