I have callbacks implements in my unity3d game in such a way that they are all nested,i.e. one callback leads to another call, whose callback leads to another call and so on upto 5 times. But the last two callbacks are losing their order. Before the second last delegate finishes execution, the last one gets executed! I am using delegates as means of message transfer (other way could be to implement interfaces). Do delegates in C# behave asynchronously by any chance? Implementin callbacks using delegates and using interfaces should yield the same results everytime, correct? And both are synchronous? Any lead on the issue would be greatly helpful.
Thanks
Depending on how you're using delegates the invocation order could not be specified.
See: Whats is the difference between nested method call and delegates?
Related
I'm currently working on replacing an old WCF client/server pairing with gRpc, and decided to use protobuf-net.Grpc as we've used protobuf-net extensively elsewhere in our codebase. I'm running into a bit of trouble with one particular portion however.
Part of the original service is a Subscribe method which uses IClientCallback to effectively send an event to the client. Looking at regular gRpc, it seems like this would be possible (though a bit hacky) using a server streaming method and storing the IServerStreamWriter object on the server, writing to it whenever we wanted to "fire an event".
For the life of me, however, I can't quite figure out how to do something similar in protobuf-net.Grpc with the IAsyncEnumerable return type. The closest I can figure is using Task.Wait in a loop and updating some shared collection when I want to "fire" the event, which the loop would then check for and yield return. This doesn't seem like it'd scale well, however, and there isn't really a great way to definitely unsubscribe when a client is no longer listening to events.
Is there some other/better way to do this?
Channel<T>, which can be tweaked via AsAsyncEnumerable() - which then essentially acts as a queue at the producer side, and a sequence at the consumer.
I have a Textbox that I want to constantly save to disk every time it is updated. I've data-bound a property to its contents, and I'm planning on adding code in the property's setter to save on change. I'm familiar with the Textbox UpdateSourceTrigger property.
Each call to save will make a call to WriteTextAsync. If the Textbox is saving every time somebody types into it, this could be generating a ton of asynchronous save calls. My simple question is, are the asynchronous write calls guaranteed to not collide and to execute in the order in which their asynchronous tasks were created?
I've read through the guides on asynchronous programming for Universal Windows Platform, and I can't find anything expressly stating this.
You won't find anything expressly stating this. This is just the nature of multithreaded development.
this could be generating a ton of asynchronous save calls
Your common sense is correct. Problems that could arise:
Saves could finish out of order.
If you close and open the file each time, Saves could collide with each other causing access exceptions.
My simple question is, are the asynchronous write calls guaranteed to not collide and to execute in the order in which their asynchronous tasks were created?
Nope. They are guaranteed to collide at some point and at some point are guaranteed to finish execution out of order from what you start them in. Limitted testing would likely show that it is ok but you'll risk the problems stated above and it would be bad practice.
You could create a manager that keeps track of the changes. The manager would put all requested changes in a queue and the Manager is the only thread that updates the text file.
I am not familar with WINAPI, and I am looking for a way to replace WaitForMultipleObjects used in one example I'm porting to Qt by anything using Qt only. Is it possible?
EDIT: (Providing more information as requested in comments)
A 3rd party API provides an array of events:
HANDLE m_hEv[MAX_EV];
In an endles-loop of a thread, the program waits for the events like this:
WaitForMultipleObjects(m_EvMax, m_hEv, FALSE ,INFINITE )
The HANDLE type seems to be void*.
So I wonder, if any Qt class could observe m_hEv for changes and unlock thread execution.
There is no simple way of porting WaitForMultipleObjects outside WinAPI. WinAPI has an "advantage" of that all lockable resources (sockets, files, processes) provide the same generic non-typesafe HANDLE, which is your void*. Unlike other platforms which have different ways of locking and signalling per the type of resource, the event handling in WinAPI is largely independent of the resources. Then a generic function like WaitForMultipleObjects can exist, which doesn't need to care who produced the HANDLEs. So you'll have to understand what the code is trying to do and mimic it differently per scenario.
The biggest difference is in WaitForMultipleObjects third parameter, which is FALSE in your case. Which means that the it will exit waiting as soon as any single event of the waiting array will happen. That is the easier scenario and can be replaced with a QWaitCondition.
Instead of m_hEv, you will pass a QWaitCondition* into the code which signals the event (most probably via WinAPI SetEvent(m_hEv[x]))
Instead of WaitForMultipleObjects, do QWaitCondition::wait().
Instead of SetEvent(), do QWaitCondition::wakeOne().
Would the third parameter be TRUE, then the WinAPI code waits until ALL m_hEv events are signalled. The established name for such functionality is a synchronization barrier and it can be simulated with QEventCondition too, but does not come out of the Qt box. I never needed to do any myself, but SO has some ideas how to do it:
Qt synchronization barrier?
WaitForMultipleObjects is a kind of generic function that works with many things: threads, processes, mutexes, etc. Qt is an OOP library where every class exposes the operations it supports. So the equivalent operation in Qt depends on what class you're using. For example, with threads, use QThread::wait. With mutexes, use QMutex::lock.
The docs for flash.utils.setTimeout() state:
Instead of using this method, consider
creating a Timer object, with the
specified interval, using 1 as the
repeatCount parameter (which sets the
timer to run only once).
Does anyone know if there is a (significant) advantage in doing so? Using setTimeout is a lot easier when you only need to delay 1 call.
setTimeout actually uses a Timer subclass, the SetIntervalTimer, which is an internal class. You can check by doing setTimeout(function ():void { throw "booom"; }, 1);. You'll see it in the stack trace.
As such, I cannot really see a big disadvantage. The only difference is, that you have 2 anonymous calls instead of one. OTOH, in performance critical situations, you shouldn't be using either (except one internal timer) to avoid frequent instantiation of TimerEvent objects.
Basically, I think it's a matter of taste. Adobe decided, the AS3 event system is the shizzle, so they promote it.
Timer:
Gives you more control as you can
register more event listeners to
receive the event rather than a
single one with setTimeout
You can control the start time and
the number of repetitions ( not very
useful against setTimeout, as this
has to run just once and after a
delay considering the immediate time
it was called)
More lines to write, even more if you
need to differentiate with parameters
( custom event class for this )
Use of event listeners which is
standard practice in as3.
Cleaner look
setTimeout:
Easier to use
Less code to write
Parameters can be easily sent;
I prefer the Timer class but I've seen setTimeout being frequently used by programmers.
Also if you are using Tweening libraries,some support delayed call
For example TweenMax
TweenMax.delayedCall(2, myFunction, ["myParam"]);
For all those who say that setTimeout is deprecated, this is non sense..
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/package.html#setTimeout%28%29
I believe you can't see any "deprecated" keyword around setTimeout here
setTimeout is working perfectly well in external .as files.
Just use this in the class :
import flash.utils.*;
import flash.events.TimerEvent;
It's my understanding that setTimeout is depreciated in AS3. I'm having a bit of trouble finding the source of the setTimeout code, but I also believe it's easier to clear up any references to the Timer object, than with setTimeout (if I remember correctly from AS2).
Usually something becomes deprecated if there becomes new and more powerful way to achieve something.
Yes setTimeout is much more easier to setup in some cases, but it is much more limited in other cases.
I would use the Timer class, because usually when something is deprecated, it means support may be removed for it sometime in the future, and then your code won't work.
The problem is, the Timer object is not at all accurate, and is subject to framerate fluctuations. Read http://forums.adobe.com/message/892631. I created my own Timer (called RealTimer) using the Date object and it is much more accurate. I recommend doing the same.
setTimeout is not working in external .as files.
I have an AIR/Flex app I made, I have a few people testing it and everyone is reporting that after leaving it running for a while, it is making all there machines run very slow. It runs fine at first so this must be a memory leak somewhere. I used the profiler on this and the only thing that shows as using a substantial amount of memory is MethodQueueElement which is not a class I wrote, and I have no idea what it does, I am assuming its part of the Flex framework. I am not familiar with using a profiler so I am not sure what all I shuld be looking at, that was the only class that was high on "memory" and it said it had over 100,000 instances. If this is my problem what can I do to fix it? I do not even know what this class does or anything about how it gets instantiated.
Thanks
The MethodQueueElement class is an internal class of the mx.core.UIComponent class.
It is used to represent on method call that has been enqueued by a callLater call.
The callLater method is part of the public interface of UIComponent, so either you call it in your code, or it is beeing called by the framework (as it happens in UIComponent.setFocus e.g.)
To free all MethodQueueElement instances, UIComponent replaces the current array of MethodQueueElements by a new (empty) one. (in the callLaterDispatcher2 method) So the only way to make a memory leak out of it is, to prevent callLaterDispatcher2 from beeing called.
To debug this, you can start to set breakpoints (while you app is running) in the methods callLater (here your instances get created, so somehow it gets called all the time, look at the stacktrace here!), callLaterDispatcher2 (i suppose it wont get called), and check whether UIComponentGlobals.callLaterSuspendCount is != 0, which could be the reason callLaterDispatcher2 doesn't get called.
Should the latter be the case, i suspect, that you have tweens or something else calling UIComponent.suspendBackgroundProcessing but then not calling resumeBackgroundProcessing (because of an exception terminating the code before reaching the resumeBackgroundProcessing call e.g.)