I am writing a Firefox extension, which is doing two things (for the context of this question):
Registering for certain DOM events, viz DOMContentLoaded and DOMFrameContentLoaded.
In the call back for the events, access the DOM APIs and do certain operations.
The extension gets the first event (either DOMContentLoaded or DOMFrameContentLoaded), and the callback function invokes some DOM APIs. I am observing, before the call returning back to my extension from the DOM API call, another event firing and my call back function getting invoked (I haven't been able to narrow down which specific DOM API, as my extension invokes bunch of DOM APIs).
Is this even possible? BTW, I am on Firefox 12 on Windows. I am printing the threadManager.isMainThread, and in both situations the event call back is being invoked on the main thread.
Any pointers will be highly appreciated.
JavaScript is generally single-threaded. However, this doesn't mean that functions cannot be reentered (a function calling itself being the most obvious example). So an event handler could still be called while another event handler is executing. AFAICT this can happen under the following conditions:
The event handler causes (directly or indirectly) another event to be generated and dispatched. In particular, DOM manipulations will cause mutation events - the processing of such events happens synchronously. E.g. calling element.setAttribute() will create DOMAttrModified event and that event will be processed before element.setAttribute() returns, including running event handlers.
The event handler is "paused". This will typically happen if a modal dialog (like alert()) is opened - the current event handler will wait for this dialog to be closed while other event handlers can still be triggered. A less common case is the usage of the yield keyword in generators.
The event handler calls nsIThread.processNextEvent(). This call might execute event handlers associated with the next event in the queue. Technically, this point is the same as the one before it - alert() will call nsIThread.processNextEvent() internally to ensure that events are processed while the caller is blocked.
Related
What is the difference between using RxSwift's MainSchedule.instance and MainSchedule.asyncInstance within the context of observeOn?
asyncInstance guarantees asynchronous delivery of events whereas instance can deliver events synchronously if it’s already on the main thread.
As for why you would ever need to force asynchronous delivery when you’re already on the main thread: it’s fairly rare and I would typically try to avoid it, but sometimes you have a recursive reactive pipeline where one event triggers the delivery of a new event in the same pipeline. If this happens synchronously, it breaks the Rx contract and RxSwift will spit out a warning that you tried to deliver a second event before the first event finished. In this case you can observe on MainScheduler.asyncInstance to break the cycle.
If I'm running some JavaScript in my iOS app using JavaScriptCore, is it possible for my native code to query whether the JavaScript is currently processing an event, and/or whether there are events waiting to be immediately processed next?
Scenario: the running JS is managing some state, and I want my UI thread to occasionally query the JS for that state, but I don't want to risk waiting too long if the JS is busy processing other events first.
I investigated a bit more, and discovered that there's a surprising answer for this question: there is no javascript event loop in JSCore, if you don't implement it.
To add further detail, execution of javascript code is always synchronous with the ObjC function that invokes it, and there is no method in Javascript to generate asynchronous execution: no setTimeout, no setInterval, no DOM and addEventListener. You have to implement these function natively, and then you have to decide the scheduling policy. If your JSContext is attached to a WebView or similar browser-like context, the WebView provides these events, and you may not be able to access them in the way you want. In this case however you may use something like Zone.js to monkey patch all functions which may generate events and implement in Javascript something that tracks what you want (which is something that's done in the video of the presentation of the technology, in the linked page)
Based on a quick perusal of the API source here:
https://github.com/phoboslab/JavaScriptCore-iOS/tree/master/JavaScriptCore/API
I don't see any function on the JSContext or JSVirtualMachine that would get you the information you're interested in.
As an alternative, you could do a callback to your ObjC code from JS each time the JS code begin/ends processing an event, and then store state information in the ObjC side so you can quickly determine if you believe the JSVM is processing an event or not.
I have an app which creates a thread which communicate with the main UI via windows messages. It simply send the message to the main app thread and received the status.
That way I am displaying modal windows and do other things.
The problem is when I have to display a form which makes a call to a com+ server.
That way I get OLE error 8001010D: An outgoing call cannot be made since the application is dispatching an input synchronous call.
I think it happens because primary SendMessage is in use and com+ calls need windows messaging for its tasks.
Anyway, In delphi I cannot display the form from a thread, but how Could I workaround the problem ... ?
Thanks
EDIT:
MAIN(UI) 2. A THREAD
A. A Thread(2) sends message to a main thread (1)
B. Main thread(1) receives the msg and before letting it come back to a thread
it displays the window.
C. The modal window in main thread wants to make a com+ call, the above error occurs.
What thread the modal window is in? 2. Which thread the COM call goes from? 3. Which thread the COM object was instantiated in? 4. Is the background thread initialized with an STA? 5. Is the modal form being shown from a SendMessage handler? – Roman R. 2 mins ago
MAIN
MAIN
MAIN
CoInitializeEx(nil, COINIT_MULTITHREADED);
yes.
The problem cause comes from inability of COM to marshal an outgoing COM call while processing SendMessage request. The error which comes up is RPC_E_CANTCALLOUT_ININPUTSYNCCALL (0x8001010D), which you are referring to. I was under impression that this only applies to SendMessage calls which are a part of incoming interthread COM requests, however this might have been a false assumption.
Your typical workaround would be to replace your SendMessage with PostMessage followed by waiting for synchronization object, event or semaphore. This way your caller background thread does not hold messaging to synchronize the calls and waits autonomously, on the main thread the message being dispatched through regular message queue and eventually reaches the same handler.
As a bonus, you have an option to safely terminate the background thread. If currently it's being locked by SendMessage API waiting for modal dialog, the suggested change would let you signal the synchronization object from the main thread and let it keep running, e.g. if you want to safely terminate it.
An alternate solution might be to call InSendMessage function and if true - defer modal UI, e.g. by again posting a message to self to pop the form up in another message handler later.
I have a method that I want to be enqueued to the UI thread message pump. How is this done in actionscript? Basically I am looking for the equivalent of System.Windows.Deployment.Current.Dispatcher.BeginInvoke() in actionscript.
All timing in the Flash Player eventually comes back to the frame rate.
Not knowing exactly what the windows API you mention does, I can only assume it sets up a method to be run at a later point (say when needed by the UI, or when the UI is about to refresh).
If that's the case then you can simply setup your method to be run on the next ENTER_FRAME or EXIT_FRAME event. In both cases you need a DisplayObject to tap into (the stage is fine). There is no built-in one-shot event subscription in AS3 at this time, so you'll need to have a stub method that runs the function you want run and then removes the event listener.
You can also instantiate a Sprite, store it in a member variable and attach the event listener to it. It does not need to be on the stage for it to receive the ENTER_FRAME event.
I have a TTimer in my application that fires every 2 seconds and calls my event handler, HandleTimerEvent(). The HandleTimerEvent() function modifies shared resources and can take 10's of seconds to execute before returning. Furthermore, I call Sleep() in the event handler to relinquish the processor at times.
I'm not sure how C++ builder's TTimer object works when it comes to calling events, so the scenario I just explained has got me thinking, particularly, whether HandleTimerEvent() gets called before a prior call has returned.
The question comes down to a couple of things.
Does the TTimer object queue the events?
Can the TTimer object call my event handler before a prior call has returned?
This reply assumes that TTimer is still implemented to use WM_Timer messages. If the implementation has changed (since 2005), please disregard.
No, the TTimer object does not queue events. It is driven by the Windows WM_Timer message, and Windows does not let WM_TIMER messages stack up in the message queue. If the next timer interval occurs and Windows sees that a WM_Timer message is already in the app's message queue, it does not add another WM_Timer messsage to the queue. (Same for WM_Paint, btw)
Yes, it is possible for a TTimer.OnTimer event to be fired even while a prior event handler is still executing. If you do anything in your event handler that allows the app to process messages, then your timer event can be reentered. The obvious one is if your event handler calls Application.ProcessMessages, but it can be much more subtle than that - if anything you call in your event handler internally calls Application.ProcessMessages, or calls PeekMessage/GetMessage + DispatchMessage, or opens a modal dialog, or calls a COM interface that is bound to an out-of-process COM object, then messages in your app message queue will be processed and that could include your next WM_Timer message.
A simple solution is to disable the timer object when you enter your timer event handler, and reenable it when you exit your timer event handler. This will prevent timer messages from firing while your event handler is still working, regardless of the message handling characteristics of your code.
I use TTimer extensively. It does not queue events. If you want it to hand off to an event handler, then create a TThread that handles your events so the Timer can continue with it's work. The timer does not operate asychronously but rather synchronously.