I'm confused by what seems to be a topic-shift. We started by discussing finalization on task-local resources, but you're here discussing finalization that falls entirely outside this scope.
By definition, I expect all finalization of task-local resources to happen within a task scope before it exits. The point is what semantics one should expect when one receives a "task X exited" indication: should all resources held by X always be finalized and reclaimed at this point? It seems so, just as we would expect from OS processes. Sandro On 17/07/2013 1:31 PM, Jonathan S. Shapiro wrote: > On Wed, Jul 17, 2013 at 10:17 AM, Sandro Magi <[email protected] > <mailto:[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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
