Observer pattern, non cooperative subscriber

Question

5.00/5 (1 vote)

See more:

Hello CP experts

What is a good way to avoid that a _non cooperative subscriber does block my app?

e.g. this is the code:
http://msdn.microsoft.com/en-us/library/ee850490(v=vs.110).aspx[^]

C#

// What if one of the observers blocks? 
foreach (var observer in observers)
   observer.OnNext(info);

Notifying each subscriber in a separate thread (which I can kill more or less clean) seems for me to be overkill.

Thank you in advance.

Posted 16-Nov-14 2:18am

User 11060979

Updated 16-Nov-14 5:46am

v2

Add a Solution

Comments

Kornfeld Eliyahu Peter 16-Nov-14 8:20am

It's a bit thin - can you elaborate on the issue...

[no name] 16-Nov-14 8:37am

It is simply Observer Pattern....and there is no guaranty that any of the subscribers is cooperative. Means you have to take into account that (because of whatever) it does not return from handler.

E.g.
foreach (var observer in observers)
observer.OnNext(info);

Who who guarantees that OnNext does not block...

Kornfeld Eliyahu Peter 16-Nov-14 8:46am

You?
An Observer that blocks on OnNext (or other event) is just wrong...

[no name] 16-Nov-14 8:51am

*lol* I'm working in Praxis not with School examples. No it is not me, it is the user of my class.

Kornfeld Eliyahu Peter 16-Nov-14 9:04am

As I know you have no way - as today, but part of future features - to set a kind of time-out on an observer's method...
As today your best shot would be Parallel.ForEach...

[no name] 16-Nov-14 9:09am

Thank you once again for your Input. Need to test this.
Bruno

Kornfeld Eliyahu Peter 16-Nov-14 9:18am

What you have to think about is
1. Is the order of notification important
2. Even the answer for (1.) is NO - do you have to wait for all the notifications to finish/fail before continue on (See wait with parallel)
3. If you left pending observers behind - do you mean to clean them up at some point? How?

[no name] 16-Nov-14 9:21am

#3 is one of my biggest concern. How to clean them up. I have no idea how to do it in a safe way :(

Kornfeld Eliyahu Peter 16-Nov-14 9:25am

Yes. I can see why...
Do this: build a solution that satisfy all your other concerns and come back with an other question - I'm sure we will cook some solution...It even possible that a solution will pop by its own...

Afzaal Ahmad Zeeshan 16-Nov-14 8:24am

How would he block the application, and how would you want to notify the subscriber?

[no name] 16-Nov-14 8:36am

It is simply Observer Pattern....and there is no guaranty that any of the subscribers is cooperative. Means you have to take into account that (because of whatever) it does not return from handler.
http://msdn.microsoft.com/en-us/library/ee850490(v=vs.110).aspx[^]

Bernhard Hiller 17-Nov-14 2:46am

What a fun to see events implemented in a way so similar to Java of year 2000...
That said, the problem is common to events and callbacks - and do not forget exceptions!

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-11-16T07:01:00

I think the observer should be agnostic to what a subscriber does. Hence, it should also be agnostic to the threading model of the subscriber. It's the subscriber should be responsible for using some other threads if it is necessary, simply because of the event or delegate mechanism used by an observer already invokes an event or a delegate instance in the same thread if does for all subscribers, synchronous or not.

Note that there is no such thing a miracle. A subscriber either use the subscription in a reasonable way or not. If handing takes too much time, this is what it is. If it is not reasonable, a subscriber should be fixed. There is nothing wrong with it. After all, if you supply a class library to some user of it, you cannot guarantee that it will be used on a correct way. All you can do is to make it clear, behaving in an expected way.

—SA

Andreas Gieriet · Accepted Answer · 2014-11-16T12:45:00

Solution 2

Depending on your system's requirement, you may employ some kind of watchdog.
E.g. after each subscribers invocation, you may reset some dedicated watchdog timer. If the timer is not reset in due time, the watchdog triggers and does whatever is appropriate for the given requirement (e.g. debug-log the over-time, ~~kill the thread~~, restart the application, etc.).
Cheers
Andi

Posted 16-Nov-14 12:45pm

Andreas Gieriet

Updated 16-Nov-14 15:26pm

v2

Comments

Sergey Alexandrovich Kryukov 16-Nov-14 21:20pm

Frankly, I cannot understand why doing it and how is that related to the question. It's not clear what action is expected after the invocation and why. Note that you need to act on the timer expiration on a separate thread, and the timer action should abort some thread, because this is the only sure way to abort who-knows-what. In advance, it is not know what thread is that. If this is the same thread as the observer's thread, you will have to abort and then restore it (handle ThreadAbortException and then call Thread.ResetAbort). Did you ever try all that? Believe me, this is not a simple part of programming. Worst thing is: you don't know what thread is that, and in case of the subscriber's thread, you don't know if it should be abort-reset or not: it depends on the subscriber's code.
—SA

Andreas Gieriet 16-Nov-14 21:25pm

Debug-logging and aborting/restarting an application - yes. killing a thread - no. As you mention, this is not easily possible since you don't know what the subscriber does. (I scratched through that option ;-)).
Cheers
Andi

[no name] 17-Nov-14 4:47am

Thank you Andi.