github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine I dare say one can already easily wait until GC occurs: just have a destructor of a throw away object clear a mutex and wait on the latter. After all destructors are called during GC. 08:38
timotimo nine: not guaranteed, and that's a total hack ;) 09:47
lizmat *if* an object is GC collected, then it *will* call any DESTROY method on it (in the next run of the GC, I believe) 11:55
that is guaranteed, is it not?
perhaps you could also clear the mutex in an END block ? 11:56
japhb lizmat: But if an object is in gen2, there's no guarantee that a GC will be a full one and thus collect the object. 18:34
Meaning, the hack would completely depend on whether the object happened to be in an area that gets swept on any given GC. 18:35
timotimo japhb: you can not cause objects to be born in gen2 18:55
so when you create a new object every time and not holding on to it, it should die the next time gc runs
japhb timotimo: Who says it is born and dies in the same nursery lifecycle? That's *at best* a race condition ... 19:54
timotimo aye, it races 19:57