So here's my use case: I have an async task wrapped in a Signal<String, NSError> that effectively executes once, and is no longer relevant (one-shot, essentially).
I'd like to observe or bind the output of this to a text field in my UI, but I can't see a way to do this that doesn't involve hanging on to a reference to the Signal's disposable and manually disposing it myself once the task has completed.
Is there a simpler way of doing this? Ideally there'd be a way to make the Signal release itself when it completes.
I feel like I'm missing something conceptually here.
Signals release their resources once they complete, error out, or if their observer(s) disconnect(s).
The disposeBag is there to disconnect the observer from the signal, but in your case, it is likely that the signal will have already released all its resources before that happens, because it will complete first.
In other words, you are overthinking it. The SDK does the right thing without you having to do anything special.
Related
I'm developing a game in pyglet, that scheduled by a simple text file like :
0:00:01;event1
0:00:02;event2
0:00:03;event3
The fact is that, among these events, some might be blocking (for instance event2 might consist in displaying instructions until a key is pressed). As a consequence, event3 might not be executed at the proper time (i.e., during the event2). For now, my strategy is to schedule one event after the other :
Execute the first event
Once the first event is finished, compute the remaining duration between the first and the second event (delta_duration)
Schedule the second event with a delay of delta_duration
... and so on
For now, I did not succeed in implementing properly a blocking event with this strategy. It seems that anything blocking the event_loop (like a sleep call during event2) is preventing even the graphical elements of event2 (text instructions) to be displayed. On the other hand, if I do not put any blocking routine (sleep) in the event2, I'm able to see the vertices, but the scheduler keeps on scheduling (!), and so the event3 comes too soon.
My question is : what would be a general strategy, in pyglet, to articulate non-blocking to blocking events ? More precisely, is it possible (desirable) to use multiple clocks for that purpose ? The pyglet documentation mentions that multiple clocks can be used but it is not very well explained.
I don't want a solution that is specific to my events example but, rather, general indications about the way to go.
It's really up to your program on what blocks. If you are using input from Python for the console window, then yes that will block because it's blocking execution of Python in general. If you have a label popup in the window that is waiting for input from an on_key_press window event, then that is completely different as it's not blocking the pyglet loop, it was scheduled within it.
If your event is a 20 second long math calculation, then that should probably be ran in a thread. You will probably have to separate the types of events in order to differentiate how they should be ran. It's hard to say because without a runnable example or sample of code, I am just guessing at your intentions.
Although it sounds more like you are wanting some sort of callback system. When execution of func1 is declared done, go to func2. There is nothing built into pyglet like this, you would have to have a clever use of scheduling. There are examples of this using pure python though. I personally use Twisted Deferred's for this.
Ok completely new to this essentially we want to be able to time out a session after 10mins. that's pretty easy.
We also want to wait for external user input -- essentially data from a multi step form. also pretty easy.
We want to be able to Task.WaitAny (waitforexternalevent("updatedata"), timeout)
But this is causing issues in the orchestration.
Individually these concepts work, however we see the Task.WaitAny to unblock and reuse the first "updatedata" event.. other "updatedata" events never reach the orchestration.
Is this expected behavior, are we mixing concepts in an invalid way, or is this a bug?
We might need to see some more of your code, but with what you've described here I think the behavior you're seeing is what should be expected.
Your orchestration is "waiting" on the timeout or the external event. Once that external event is triggered, the orchestration is going to move forward and, even if something triggers that event again, the orchestration is not expecting/waiting on it.
Again, this is based on the sliver of code you've included in your question thus far. If you need to handle the event being broadcast into the orchestration multiple times you would need to have a loop of some kind.
I'm rewriting existing real-time kernel TNKernel; I have used it for a couple of years, but I don't like many of its design decisions (as well as implementation details), so I decided to fork it and have fun implementing what I want. Anyone who is interested might read additional information at the project page on bitbucket.
TNKernel has one strange, in my opinion, feature: it has service tn_task_sleep(int timeout) which puts current task to sleep, and it has tn_task_wakeup(struct TN_Task *task) which wakes currently sleeping task up.
The strangeness is that it is legal to call tn_task_wakeup() on non-sleeping task; in this case, special flag like wakeup_request will be set, and on the next call to tn_task_sleep() this flag will be cleared, and task won't sleep.
All of this seems to me as a completely dirty hack, it probably might be used as a workaround to avoid race condition problems, or as a hacky replacement for semaphore.
It just encourages programmer to go with hacky approach, instead of creating straightforward semaphore and provide proper synchronization. So, I'm willing to remove this service from my project. Is this good idea to get rid of it, or have I missed something important? Why do we ever need that?
Since no one said that I'm wrong, I assumed that I'm right and removed these strange "features" from my kernel.
I have a worker thread in a class that is owned by a ChildView. (I intend to move this to the Doc eventually.) When the worker thread completes a task I want all the views to be updated. How can I make a call to tell the Doc to issue an UpdateAllViews()? Or is there a better approach?
Thank you.
Added by OP: I am looking for a simple solution. The App is running on a single user, single CPU computer and does not need network (or Internet) access. There is nothing to cause a deadlock.
I think I would like to have the worker thread post (or send) a message to cause the views to update.
Everything I read about threading seems way more complicated than what I need - and, yes, I understand that all those precautions are necessary for applications that are running in multiprocessor, multiuser, client-server systems, etc. But none of those apply in my situation.
I am just stuck at getting the right combination of getting the window handle, posting the message and responding to the message in the right functions and classes to compile and function at all.
UpdateAllViews is not thread-safe, so you need to marshal the call to the main thread.
I suggest you to signal a manual-reset event to mark your thread's completion and check the event's status in a WM_TIMER handler.
suggested reading:
First Aid for the Thread-Impaired:
Using Multiple Threads with MFC
More First Aid for the Thread
Impaired: Cool Ways to Take Advantage
of Multithreading
In a GC enabled language, when observer subscribes to events of subject, actually subject got a reference of observer.
So before drop an observer, it must un-subscribes first. Other wise, because it's still referenced by subject, it will never be garbage collected.
Normally there are 3 solutions:
Manually un-subscribes
Weak Reference.
Both of them cause other problems.
So usually I don't like to use observer patterns, but I still can not find any replacement for that.
I mean, this pattern describes thing in such a natural way that You could hardly find anything better.
What do you think about it?
In this scenario, you can use finalize() in Java. finalize() is a bad idea when you have to release a resource (like a DB connection) because some outside system is affected. In your case, the object which installed the observer will be GC'd during the runtime of your app and then, finalize() will be called and it can unsubscribe the observer.
Not exactly what you want but someone must decide "it's okay to unsubscribe, now". That either happens when your subject goes away (but it should already kill all observers) or the object which installed the observer.
If your app terminates unexpectedly, well, it doesn't hurt that finalize() might not be called in this case.
If you want to remove an observer you should inform the publisher by unsubscribing, first, otherwise it will try to send out events and depending on how it is written, it could crash the app, quietly ignore the error or remove the observer. But, if you open something, close it; if you subscribe, unsubscribe.
The fact that you are not unsubscribing is a bad design, IMO. Don't blame the pattern for a poor implementation.
The observer pattern works well, but if you want to alleviate some of the issues, you could use AOP for the implementation:
http://www.cin.ufpe.br/~sugarloafplop/final_articles/20_ObserverAspects.pdf
Consider the scenario of an object which counts how often some observable thing changes. There are two types of references to the object: (1) those by entities which are interested in the count; (2) those used by the observable thing(s) which aren't really interested in the the count, but need to update it. The entities which are interested in the count should hold a reference to an object which in turn holds a reference to the one that manages the count. The entities that will have to update the count but aren't really interested in it should just hold references to the second object.
If the first object holds a finalizer, it will be fired when the object goes out of scope. That could trigger the second object to unsubscribe, but it should probably not be unsubscribed directly. Unsubscription would probably require acquiring a lock, and finalizers should not wait on locks. Instead, the finalizer of the first object should probably add that object to a linked list maintained using Interlocked.CompareExchange, and some other thread should periodically poll that list for objects needing unsubscription.
Note, btw: If the first object holds a reference to second object, the latter would be guaranteed to exist when the finalizer for the first object runs, but it would not be guaranteed to be in any particular state. The cleanup thread should not try to do anything with it other than unsubscribe.