I'm starting Simperium in the application launch process. All works ok until objects are saved in a context other than the one used to start the simperium instance. Should these "buckets not loaded..." errors be ignored or should I be managing the simperium instance and NSManagedObjectContexts for background threads differently? Thanks!
Unfortunately multiple contexts aren't yet supported. Simperium expects a single context, which clearly isn't ideal. You can track this issue on GitHub, or if you're feeling brave take a stab at adding support for it yourself (the library is open source). It'll be a little hairy though.
Related
I need to process AJAX in my crawler and would prefer using system browser albeit I may have to change my mind. My crawler program may generally be working in background while the user can work on other stuff in other applications.
Anyhow - since WebControl leaks memory if processing JS libs that leak memory - this can cause a crawler to quickly run out of memory. (Many SO posts about this.)
So I have created a solution that uses a separate "dummy" small executable with the webcontrol that takes input/output. This is launched as a separate process by the crawler. This part seems to work great. This child process is created/destroyed as many times as needed.
However, this called process with the embedded-IE grabs focus on every page load (a least if e.g. JS code calls focus) which means if the user is doing work in e.g. Word or whatever - keyboard focus is lost.
I have already moved the embedded IE window off-screen, but I can not make it invisible in the traditional sense since then the embedded IE stops working.
I have tried to disable all parent controls before calling navigate - but it does not work for me.
Any ideas I have not tried? Maybe somehow catch a windows message that focuses webcontrol and ignore it? OR something so I can immediately refocus the earlier control that had focus?
I currently use Delphi - but this question is applicable to VB, C# .Net etc. from my earlier investigations on this matter. I will take a solution and ideas in any language.
I'm writing a command line tool for installing Windows services using Node JS. After running a bunch of async operations, my tool should print a success message then quit. Sometimes however, it prints its success message and doesn't quit.
Is there a way to view what is queued on Node's internal event loop, so I can see what is preventing my tool from quitting?
The most typical culprit for me in CLI apps is event listeners that are keeping the process alive. I obviously can't say if that's relevant to you without seeing your code, though.
To answer your more general question, I don't believe there are any direct ways to view all outstanding tasks in the event loop (at least not from JS-land). You can, however, get pretty close with process._getActiveHandles() and process._getActiveRequests().
I really recommend you look up the documentation for them, though. Because you won't find any. They're undocumented. And they start with underscores. Use at your own peril. :)
try to use some tools to clarify the workflow - for example, the https://github.com/caolan/async#waterfall or https://github.com/caolan/async#eachseriesarr-iterator-callback
so, you don't lose the callback called and can catch any erros thrown while executing commands.
I think you also need to provide some code samples that leads to this errors.
I have been asked to debug, and improve, a complex multithreaded app, written by someone I don't have access to, that uses concurrent queues (both GCD and NSOperationQueue). I don't have access to a plan of the multithreaded architecture, that's to say a high-level design document of what is supposed to happen when. I need to create such a plan in order to understand how the app works and what it's doing.
When running the code and debugging, I can see in Xcode's Debug Navigator the various threads that are running. Is there a way of identifying where in the source-code a particular thread was spawned? And is there a way of determining to which NSOperationQueue an NSOperation belongs?
For example, I can see in the Debug Navigator (or by using LLDB's "thread backtrace" command) a thread's stacktrace, but the 'earliest' user code I can view is the overridden (NSOperation*) start method - stepping back earlier in the stack than that just shows the assembly instructions for the framework that invokes that method (e.g. __block_global_6, _dispatch_call_block_and_release and so on).
I've investigated and sought various debugging methods but without success. The nearest I got was the idea of method swizzling, but I don't think that's going to work for, say, queued NSOperation threads. Forgive my vagueness please: I'm aware that having looked as hard as I have, I'm probably asking the wrong question, and probably therefore haven't formed the question quite clearly in my own mind, but I'm asking the community for help!
Thanks
The best I can think of is to put breakpoints on dispatch_async, -[NSOperation init], -[NSOperationQueue addOperation:] and so on. You could configure those breakpoints to log their stacktrace, possibly some other info (like the block's address for dispatch_async, or the address of the queue and operation for addOperation:), and then continue running. You could then look though the logs when you're curious where a particular block came from and see what was invoked and from where. (It would still take some detective work.)
You could also accomplish something similar with dtrace if the breakpoints method is too slow.
I have always read and worked off a single UI thread since having more than one will screw up message pumping etc etc.
I am answering my own question here but want to validate my understanding on Chrome browser which is known to have multiple processes ( one per tab ) - does it also accelerate some bit on the rendering part by employing multiple UI threads ?
My guess is it does NOT , but if it does It would be very interesting to know or look at some sample c# code to demo the same ( does not have to be web browser demo).
Any pointers in the multiple UI thread direction would help! thanks.
I cant state definitively how Chrome handles the rendering threads - but I would assume that each tab has its own rendering thread. I wouldnt see the point of going through all the effort of process isolating the tabs, only to tie them all together on a common rendering thread. They would all have the opportunity to interfere with each other.
I implemented a 'chrome-style' browser using WPF - the application shell was a single process, then each 'tab' was a MAF AddIn running in a separate process. The rendering was all in child processes - there was nothing shared. Each AddIn returned an INativeHandleContract (a WPF control) which was passed across the process boundary.
The upshot of this, was that an exception ANYWHERE in a child tab, would only take down the tab, and could be detected by the parent process, giving it a chance to provide some feedback/reload the tab etc.
This document wasnt around when I achieved it, but after a quick browse I think it has some pointers:
http://msdn.microsoft.com/en-us/library/bb909794.aspx
Kent Boogaart also lent a helpful hand
http://kentb.blogspot.com/2008/06/maf-gymnastics-service-provider.html
You may also need this QFE from Microsoft to fix a bug in serialization you may experience when passing a WPF control across a process boundary:
http://archive.msdn.microsoft.com/KB982638
In regards to MS Connect bug: https://connect.microsoft.com/VisualStudio/feedback/details/467381/wpf-controls-cannot-be-passed-across-process-boundaries
Don't confuse threads and processes. Each process will have it's own ui thread, but likely also it's own message pump.
I am trying to run dvipng process from a thunderbird extension using Components.interfaces.nsIProcess. I need to read standard output of the process, but I am not able to find a way to do that. I found some threads on nsIProcess2, but that one was (as it seems) never fully implemented with stdout. Any suggestions?
nsIProcess2 is unrelated - it was implemented but later folded into nsIProcess. It was only about starting processes asynchronously.
The relevant bugs are bug 484246 and bug 68702. The latter has been resolved but so far that code doesn't ship with Firefox/Thunderbird by default (it's quite a bit of code that neither Firefox nor Thunderbird need themselves). So your options are:
Build IPCModule yourself and make it part of your extension - not recommendable because it will cause lots of troubles.
Create a native library that will call dvipng for you, use it via js-ctypes - should be the easiest solution.
Turn dvipng into a library and use it directly via js-ctypes - probably not too hard either, this will also give you better performance.