|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:09
fake_space_whale left
06:59
domidumont joined
07:20
krunen left,
krunen joined
07:50
domidumont left
07:59
avar left
08:03
avar joined,
avar left,
avar joined
|
|||
| 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 | |
|
08:54
robertle joined
|
|||
| 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 | ||
|
14:51
lucasb joined
16:43
zakharyas joined
17:11
patrickb joined
17:36
patrickb left
|
|||
| 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 | |
|
20:16
zakharyas left
21:51
harrow left
22:01
harrow joined
22:46
lucasb left
|
|||