Section 13.8 of TDPL has this to say on how thread termination should behave:
"The most important manifestation of the owner/owned relationship is that when the owner thread terminates, the calls to receive in the owned thread will throw the Own- 5 erTerminated exception. The exception is only thrown if receive has no more match- ing messages and must wait for a new message; as long as receive has something to fetch from the mailbox, it will not throw. In other words, when the owner thread termi- nates, the owned threads’ calls to receive (or receiveOnly for that matter) will throw OwnerTerminated if and only if they would otherwise block waiting for a new message." This is how it's currently implemented, but I've been wondering about this behavior vs. simply throwing when processing of the message queue encounters the OwnerTerminated message. If an owned thread receives a steady stream of messages from other sources, it will never terminate under the current model. Is this really the desired behavior? I think a case could be made either way, but I haven't come up with a conclusive argument in support of either approach. I mostly bring this up because the current behavior treats the OwnerTerminated message differently from all other messages, and I'm wondering if the special treatment is warranted. The file copy example would work exactly the same either way. The only difference would be with more complex cases where an owned thread was talking to other threads as well. Thoughts? _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
