From: Robert Klemme <shortcutter@...>
Date: 2011-06-27T16:20:16+09:00
Subject: Re: Single Responsibility Question

On Sun, Jun 26, 2011 at 2:22 AM, Mike Bethany <mikbe.tk@gmail.com> wrote:
> 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.

This is the an implementation of the observer pattern.  Ruby's
standard library has an implementation of this already (see ri
Observable).
http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html

> 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?

The observable (watched object) is responsible for maintaining its own
integrity (with regard to functional and maybe also performance
requirements).  If those mandate that it cannot risk being blocked by
observers then it must create the thread (or ensure concurrent
execution by other means, e.g. Fibers).

Btw, there is no responsibility needed after creation of the thread:
it will terminate eventually and that's it.  The story is a tad
different if you create the thread on object construction and use a
queue for concurrent notification execution.

> 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.

Typically *many* listeners (or observers) can register with a single
observable.  If the observable must make sure it doesn't get blocked
by listeners then it should create the thread.  If on the other hand
you want to keep the implementation lightweight, keep # of threads low
or need to make sure that observers can prevent an operation in the
observable (e.g. by raising an exception) the thread must not be
created in the observable (because you need to wait for observers to
finish anyway).  There may also be other reasons which prevent usage
of a separate thread (i.e. if observers must be able to see the state
of the observable /before the modifying method terminates/).

As you can see there are various aspects and different situations may
require different handling of this.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/