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
hi Mike,
don’t know what you’re using now (sounds hectic,) but maybe check out
the observer pattern, it keeps things nice and simple…
http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html
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 B. [email protected]
On Sun, Jun 26, 2011 at 2:22 AM, Mike B. [email protected]
wrote:
Tend to agree with your analysis, even so far that I believe you might
reconsider where to create the thread.
The listener would spring into mind. But probably you need some kind
og queuing as has been pointed out by
Stephen.
HTH
Robert
Thanks for the replies guys.
This is a mixin module so I have no control over the listener code. Even
if
I did though requiring the listener to queue messages to make the
watched
object work properly seems like a really bad idea because you’re making
listeners do the watched object’s job; namely making sure the watched
object
doesn’t break. The watched object shouldn’t know anything about the
listeners; not even how quickly or efficiently they run their callback
function. If a listener needs to do something that could take a long
time it
should probably make sure it is a good citizen and doesn’t shutdown
everything (unless it needs to) but the watched class shouldn’t know
anything about that. All it should know is, “I need to tell this object
that
something happened and this is the method I call on that object to do
that.”
It’s also the DRY principle: if you required every listener to
do something that could be done in one place then you
are unnecessarily repeating yourself.
I am looking at implementing the Actor model though in the Eventable
module
for adding and removing event listeners.
Thanks again for the feedback,
Mike
On Sun, Jun 26, 2011 at 2:22 AM, Mike B. [email protected]
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
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
Thanks Robert, you always have excellent feedback.
On Mon, Jun 27, 2011 at 3:20 AM, Robert K.
[email protected]wrote:
On Sun, Jun 26, 2011 at 2:22 AM, Mike B. [email protected] 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 (GitHub - mikbe/eventable: Eventable is an easy to use and understand event model; it's the simplest way to add fine-grain events to your classes.) 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. =)
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.
On Tue, Jun 28, 2011 at 10:57 AM, Robert K.
[email protected] wrote:
Incidentally keeping things as simple as possible often helps with the
robustness as well: the lesser nuts and bolts there are less things
can break and usually the lower the likeliness of things to break. 
Not to mention: the fastest code is the code that never gets executed,
and it’s easier to test code that doesn’t has to be written, too. 
It’s always good to keep different aspects separate - that’s all
modularity is all about. And modularity not only enables reuse
but foremost it makes understanding code easier.
That’s what is behind “composite objects” or “component object model”:
Instead of building intricate object hierarchies with complex
inheritance relationships to gain functionality, you compose your code
such that you can “build” your objects from components.
Yes, the theory reminded me of Ruby’s mixins, too.
Here’s a link exploring composite objects in greater detail:
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
P.S.: This is a resend, since SpamAssassin doesn’t seem to like me all
that much.
–
Phillip G.
A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz
On Mon, Jun 27, 2011 at 3:27 PM, Mike B. [email protected]
wrote:
Thanks Robert, you always have excellent feedback.
Thank you!
I wrote Eventable (GitHub - mikbe/eventable: Eventable is an easy to use and understand event model; it's the simplest way to add fine-grain events to your classes.) 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.
If requirements are different then a different solution is needed.
That’s why “observer” is a pattern - implementations can differ.
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. =)
As you can see there are various aspects and different situations may
require different handling of this.
Thanks again Robert. My vision is to keep Eventable as lightweight as
possible while still making it as robust as possible.
Incidentally keeping things as simple as possible often helps with the
robustness as well: the lesser nuts and bolts there are less things
can break and usually the lower the likeliness of things to break.
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.
It’s always good to keep different aspects separate - that’s all
modularity is all about. And modularity not only enables reuse
but foremost it makes understanding code easier.
Kind regards
robert