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?

Here's another fun one.  If a thread A spawns a thread B and sets its maxMailboxSize to some finite number with OnCrowding.ignore set and then terminates when thread B's mailbox is full the OwnerTerminated message will never be received.  I'm inclined to say that the crowding limit should only apply to user-initiated messages, and that system messages are exempt.  Does this sound reasonable?

On 6/17/10 23:10 PDT, Sean Kelly wrote:
> Here's another fun one.  If a thread A spawns a thread B and sets its maxMailboxSize to some finite number with OnCrowding.ignore set and then terminates when thread B's mailbox is full the OwnerTerminated message will never be received.  I'm inclined to say that the crowding limit should only apply to user-initiated messages, and that system messages are exempt.  Does this sound reasonable?

I think that is reasonable, yes.

Andrei

This is a good question. It looks like a fairness mechanism should be in place to ensure that a thread under high message pressure will stop in a timely manner.

On the other hand, I think it's reasonable to assume that the application that does feature such a high throughput message source would also send _that_ thread a termination message. That means that the high-frequency message emitter will ultimately stop, then the pressured receiver will stop too, and everybody's happy.

I suggest we continue with this strategy and only tweak it if the necessity appears.


Andrei

On 6/17/10 7:53 PDT, Sean Kelly wrote:
> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos