--20cf3071cc6286178a04a6944d56
Content-Type: text/plain; charset=ISO-8859-1

If the code/logic on the listener side were lightweight then you may permit
the  'watched' thread to invoke the "client" (/listener) side code.   If
instead the listener side code is longer (either in cpu or in wall clock
time) then you might consider queuing the callback invocations on the
listener side. The listener callback code would queue the information from
the the watched thread invoking it and then allow that watched thread to
return.


2011/6/25 Mike Bethany <mikbe.tk / gmail.com>

> I'm trying to figure out who's responsible for a resource.
>
> Here's the situation:
> An object, the listener, tells another object, the watched, to tell it when
> something happens. When the event happens the watched object creates a
> thread to call the listener's callback method.
>
> My question is who's responsible for the thread? The watched object created
> it but only to make sure the listener's method doesn't block any other
> methods the watched object needs to call in any other listeners.
>
> Right now the thread goes out of scope almost immediately in the watched
> object (it's created in a loop) so the listener is the only thing holding a
> reference open to that thread. This seems like the right way to do it but
> I'm worried about run away threads. Or if the watched object should even be
> worried about it.
>
> Typing this out makes it seem pretty clear to me that even though the
> watched object created the thread the listener is responsible for it. The
> watched object should not be responsible for the listener's code. Right?
>
> I want to make sure I'm not just convincing myself though, that I forgotten
> something I should have thought of. If anyone has any input on this please
> let me know, thanks.
>
> Mike
>

--20cf3071cc6286178a04a6944d56--