From: Mike Bethany <mikbe.tk@...>
Date: 2011-06-27T22:27:31+09:00
Subject: Re: Single Responsibility Question

--0016e6433954daec4104a6b18262
Content-Type: text/plain; charset=ISO-8859-1

Thanks Robert, you always have excellent feedback.

On Mon, Jun 27, 2011 at 3:20 AM, Robert Klemme
<shortcutter@googlemail.com>wrote:

> 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.
>
> standard library has an implementation of this already (see ri
> Observable).
> http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html
>
>
I wrote Eventable (https://github.com/mikbe/eventable) specifically because
Observable didn't do everything I wanted, e.g. fine-grain event control and
better handling of abandoned listeners. Also Observable doesn't use any
mechanism to prevent blocking callbacks and that was a must.


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


Excellent. I had come to that conclusion but it's good to hear I'm right. =)


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



Thanks again Robert. My vision is to keep Eventable as lightweight as
possible while still making it as robust as possible. I don't think it
should be Eventable's job to monitor threads but I do have the need to
monitor for run away threads in the application I originally wrote Eventable
for.

To solve this issue I've decided to create a thread monitor mixin for that
responsibility. This will allow the the user of Eventable to specify thread
monitoring behavior without adding another responsibility to Eventable.

--0016e6433954daec4104a6b18262--