In my app I have a plugin system that allow users to develop plugins (in C/C++ dylib) and execute them at runtime (using dlopen/dlsym).
Basically I have a main thread (which is drawing my GUI) and another thread (which is the plugin thread) that is loading/running the plugin.
What I would like to do is to allow the user to debug is plugin in Xcode and keep the main thread running.
I already know that in XCode you can create a dylib project and set in Info > Launch > Wait for ??? to launch (which work great), but the problem Im having with that is:
If the user stop the dylib debugging it close the main application launched (my app, which I don't want as I want to keep it running).
It stall the main application thread completely (the GUI stop refreshing until the user continue).
Is there any way to still allow the users to use XCode to develop/debug their plugins avoiding the 2 problems above?
Or I'll have to integrate a text editor and somehow interface clang++/lldb directly inside my app to let the users develop/debug (which sounds to me like alot of work, especially since XCode already have all the functionalities)?
TIA!
lldb has the ability to run all threads when you step or next, but when you interrupt the program (press Pause), all threads will be stopped. lldb doesn't currently have any UI to do what you want -- there's no technical limitation but I don't think I've seen a use case that called for this behavior. There was an obscure command added to gdb, thread dont-suspend-while-stepping which would designate a specific thread and tell gdb to allow that thread to run whenever the debugger was step/nexting, but even in that case when you interrupted the program all threads would be stopped..
Related
I am writing a small application (.exe) that does some tasks and then returns an exit status. It is meant to be run regularly from another application (which I have no control over) that uses the status code to determine further action.
It works just fine if I compile and link it as a console app. However, that makes the console window flash briefly on the screen every time it is run, which is a little bit annoying. I tried to make it a Windows app, but the problem then is that Windows releases control to the calling application (or the OS) immediately after start. Thus, any exit status my application generates is returned too late and is never seen by the calling application.
Is there a way to force my app to stay in the foreground, so to speak, and not release control before it actually exits? I tried to force the entry point to be the "main" function instead of "WinMain", but that didn't help.
It isn't a question of whether the child "releases control" or not - Windows is a preemptive multitasking operating system, so all processes run at once. If the parent process waits for the child to exit, it is because the programmer told it to wait for the child to exit.
It isn't easy to make a program wait for console programs but not non-console programs. The command shell (cmd.exe) works this way when run interactively, but there isn't any API that does this as far as I know. Assuming that it isn't deliberate - which would be very strange in this context - the only explanation I can think of is that the program is running an interactive command shell and feeding in your command via standard input. That's the wrong thing to do, but I have seen people trying to do it that way before.
Presumably you can choose the command line that the parent executes. Try this:
start /wait myapp.exe
(That's how you would do it in an interactive command shell.)
If that doesn't work, you may have to consult the author of the parent process for advice.
I'm facing an issue with TerminateProcess() function.
The application I'm currently writing a JobScheduler app that schedules and launches job at a specific time.
For this purpose, I'm using CreateProcess() to execute my JobLauncher.
The JobLauncher process then launches a console program (using createprocess ) which effectively executes the job executable, waits for its termination and monitors the duration, user and kernel times elapsed etc.
In order to kill the job from the JobScheduler I firstly started using TerminateProcess() but it does not allow me to close the executable itself properly. I mean i found no way to hook any termination event.
Until I find a better way than a brutal TerminateProcess(), I wrote an intermediate solution using the GenerateConsoleCtrlEvent() in the calling program.
In the job application that launches the target job executable, I installed a handler using SetConsoleCtrlHandler().
And in the handler, I can terminate the process of the job and notifies my thirdparties properly.
This is the better solution I found for now.
Is there a better way to programmaticaly and properly close a process ?
Do you this solution is completly absurd ?
I'm not a "system-level" specialist developer though...
Z.
This well know Windows console problem and you can find some solutions here.
We used on internal console utility which has name "Kamikaze". It worked as described here and for me it's a best solution cause there is no problem with porting between Windows versions and Windows architectures (x86, x64).
I call a DLL written in C++ (VS2012) from a software (LabView) and what it does is uploading a file on a server via FTP.
While the DLL is uploading the file (15MB) it does not let LabView continue with other tasks.
How could this problem be solved?
Regardless of what you have to do on the C++ side to make the call threadsafe, you will need to configure the call in LabVIEW not to run in the UI thread (which I believe is the default configuration, for safety reasons). Double click the node and select the run in any thread option.
Also, if you want to ensure running it in its own thread, you can put it in a separate VI and change the execution settings of that VI to run in a different execution system. LabVIEW doesn't give you direct control of threads, because it manages them on its own, but this should make the VI execute in a different thread.
Operations with FTP are long-term.
It is better to perform such operations in another thread.
I am writing an application in Qt which gets executed by a launcher app. How can I detect whether the Qt application was launched by the user or the launcher. Is command line parameters the only way or is there a better way?
Both the Qt app and launcher are written by me.
Lots of ways. A command line parameter could be easily sniffed (by Process Explorer, e.g.), if that's a concern. But a named mutex or some other interprocess handle that can be inherited by the child app would be more difficult to spoof.
I'm going through Qt tutorials on OSX. One thing I noticed is that when I launch the executable (e.g. the push button hello world example), the app will launch as a background window and I have to switch tasks to bring it into the foreground. How can I force the Qt application window to be the foreground window upon execution?
I'd like to do this since it's how most apps behave, not to mention that manually switching tasks slows down my edit-compile-run-debug cycle).
The behavior you observe is due to interaction with the debugger when you start the application under the debugger using ⌘-Y. If you simply run it using ⌘-R, it behaves as you expect. Your application itself is fine.
Starting OS X applications by directly firing up the executable from within the app bundle from the terminal will act similarly to running them using ⌘-Y -- they all start in the background. Qt is probably mimicking whatever magic Finder does when it starts the process via ⌘-R -- said magic may reduce to simply bringing the child app to the foreground. gdb on OS X is not so "clever", and probably for a good reason.
OS X approach is to try harder not to steal focus -- a good thing IMHO.
If you merely want to run the application, not debug it, then modify your launch command to look like open -a '/Users/daj/foo/bar/baz.app', where baz.app is the app bundle folder. Do not append a trailing slash.
If you can coax your debugger to follow through to child processes, then you can of course launch open itself under gdb, and it will work as expected -- with your child application on top.