On 19 July 2013 06:06, Sandro Magi <[email protected]> wrote: > The story is less clear with tracing because you have to do some extra > work to either run a task-local GC using the task thread, or track via a > task-local flag whether a task has been GC'd and thus it's safe to > display that the task is done, ie. you have to add extra laziness to > handle the laziness of GC reclamation:
Speaking generally, you're right. However, if disposables cannot escape a task anyway, then disposables are task-local, so you already know (or, already can track) what needs to be disposed of at task exit. If they do escape, then it can be useful to describe the means by which they may escape, and disposal mechanisms can be extended appropriately. For capability security reasons, it is probably useful to be able to hand resources to tasks at least, but I don't think rust currently allows such a thing. In any case, for a large number of programs, there needs to be a way to specify finaliser order. RAII is one way, weakref callbacks another, and I hinted at a different method on cap-talk a while back. Refcounting is an acceptable method, although potentially ambiguous - certainly in cpython at least, where reference cycles involving objects with finalisers are actually never reclaimed. It's easier to make that mistake when resource lifetime and domain object lifetime are so intimately connected, less so when you're forced to actually think about your dependencies: obviously you can do the same thing with weakref callbacks, it's just more obvious when you do. We don't usually think of disposables as being related to one another anyway, so the problem is not as wide in practice as it could be. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
