On Wed, Jul 17, 2013 at 10:17 AM, Sandro Magi <[email protected]>wrote:
> I don't think we're on the same page. I'm not suggesting tracing is > required, I'm suggesting that the expected task semantics includes > prompt reclamation/finalization of resources. Ref counting provides > this, tracing does not. > > Then we're *definitely* not on the same page. First, finalization by it's nature cannot be relied on to be prompt. Introducing the expectation that finalization will be prompt - anywhere - has a long history of inducing problems in software that depends on this behavior. Correctly used, finalization is a last-gasp recovery technique to be used when an application has bungled its explicit resource management. As an aside, this is one reason to like the notion of an "owning" pointer - running a finalizer when an owning pointer goes out of scope can reasonably be both prompt and effective, and very often fits the usage pattern of real applications. Second, running finalizers after task exit is *very* problematic. Executing the finalizers may involve unbounded computation, and the task is *gone*. No code should be running in it at that point. Which brings me to... Third, if task death runs *application level* resource reclamation, we have a fairly important layering violation. It's perfectly fine for the underlying OS resources to get cleaned up or closed or whatever, but completely *unreasonable* for in-task finalization code to be executed. Caveat: there's a huge difference between a task calling FinalizeAndExit() on itself vs. a task being destroyed by a second task. I'm not saying FinalizeAndExit() is a bad thing. I'm saying that DestroyTask(thatOne) is an operational requirement, and *that* operation must not run finalization code within the target task. Indeed, one of the reasons we might be killing off the target task is that it's blocked indefinitely on some OS resource and completely in able to make progress. And come to think of it, I suppose I'm making some assumptions here about task semantics that may not be correct: namely that a task can hold OS-level resources that logically are *not* owned by it's parent task or containing runtime environment. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
