I use _getch() in one thread of my multi-thread Windows console program, which is built with Visual C++. If I press a little faster, _getch() misses some inputs. For example, I enter a string "hello", bug _getch() gets the characters 'h', 'l','l','o'. It missed 'e'. If I press a little slower, it gets all the characters. There are 6 threads altogether with a 3rdparty library.
If I do not use the 3rdparty library, there are 3 threads. Everything works OK.
So is there any possibility that 3rdparty code modifies the attribute of the console that leads the problem?
It turns out that the 3rdparty library, in another thread, is stealing keyboard inputs.
Related
This is what says on http://invisible-island.net/ncurses/ncurses.faq.html#multithread
If you have a program which uses curses in more than one thread, you will almost certainly see odd behavior. That is because curses relies upon static variables for both input and output. Using one thread for input and other(s) for output cannot solve the problem, nor can extra screen updates help. This FAQ is not a tutorial on threaded programming.
Specifically, it mentions it is not safe even if input and output are done on separate threads. Would it be safe if we further use a mutex for the whole ncurses library so that at most one thread can be calling any ncurses function at a time? If not, what would be other cheap workarounds to use ncurses safely in multi-thread application?
I'm asking this question because I notice a real application often has its own event loop but relies on ncurses getch function to get keyboard input. But if the main thread is block waiting in its own event loop, then it has no chance to call getch. A seemingly applicable solution is to call getch in a different thread, which hasn't caused me a problem yet, but as what says above is actually not safe, and was verified by another user here. So I'm wondering what is the best way to merge getch into an application's own event loop.
I'm considering making getch non-blocking and waking up the main thread regularly (every 10-100 ms) to check if there is something to read. But this adds an additional delay between key events and makes the application less responsive. Also, I'm not sure if that would cause any problems with some ncurses internal delay such as ESCDELAY.
Another solution I'm considering is to poll stdin directly. But I guess ncurses should also be doing something like that and reading the same stream from two different places looks bad.
The text also mentions the "ncursest" or "ncursestw" libraries, but they seem to be less available, for example, if you are using a different language binding of curses. It would be great if there is a viable solution with the standard ncurses library.
Without the thread-support, you're out of luck for using curses functions in more than one thread. That's because most of the curses calls use static or global data. The getch function for instance calls refresh which can update the whole screen—using the global pointers curscr and stdscr. The difference in the thread-support configuration is that global values are converted to functions and mutex's added.
If you want to read stdin from a different thread and run curses in one thread, you probably can make that work by checking the file descriptor (i.e., 0) for pending activity and alerting the thread which runs curses to tell it to read data.
Why does this crash FireFox? Copy and paste this code into the browser console (Ctrl+Shift+J):
function TestRunner(){}
TestRunner.prototype={
classDescription:"TestRunner",
classID:Components.ID("{09AA3487-7531-438D-B0B2-80BC24B584C0}"),
contractID:"#yoy.be/TestRunner;1",
QueryInterface:XPCOMUtils.generateQI([Components.interfaces.nsIRunnable]),
run:function(){
console.log("ping");
}
};
Components.classes["#mozilla.org/thread-manager;1"].getService().newThread(0).dispatch(new TestRunner(),0);
Starting with Firefox 4(-ish) the whole Javascript engine became far less thread safe, to the extend where e.g. simple things such as just "reading" a string concurrently may cause memory corruption (because these reads might actually materialize strings views for string ropes).
Therefore it was decided that dispatching javascript-implemented nsIRunnable isn't supported anymore as there is no safe way to use it, and people should switch over to ChromeWorkers where possible.
Edit You said in the comments that you wanted to implement nsIChannel/nsIProtocolHandler. AFAIK you can implement nsIProtocolHandler and nsIChannel without any threads and binaries. If you still have to have threads and/or binaries, then your Javascript XPCOM (stub) components would "simply" communicate with a ChromeWorker via message passing (pass around ArrayBuffers/typed arrays; those are zero-copy). The ChromeWorker would then do any heavy lifting, incl. any js-ctypes calls to interface with binaries.
You can run non-XPCOM JavaScript on other threads using (chrome) workers, and you can dispatch C++ implementations of nsIRunnable to other threads, but you can only use XPConnect on the main thread. This is because XPConnect objects could be cycle-collected and the cycle collector isn't threadsafe.
I'm using 3.9.7 cURL library to download files from the internet, so I created a dynamic bibioteca of viculo. dll written in C using VC + + 6.0 the problem is that when either I call my function from within my vb6 application window locks and unlocks only after you have downloaded the file how do I solve this problem?
The problem is that when you call the function from your DLL, it "blocks" your app's execution until it gets finished. Basically, execution goes from the piece of code that makes the function call, to the code inside of the function call, and then only comes back to the next line after the function call after the code inside of the function has finished running. In fact, that's how all function calls work. You can see this for yourself by single-stepping through your code in the VB 6 development environment.
You don't normally notice this because the code inside of a function being called doesn't take very long to execute before control is returned to the caller. But in this case, since the function you're calling from the DLL is doing a lot of processing, it takes a while to execute, so it "blocks" the execution of your application's code for quite a while.
This is a good general explanation for the reason why your application window appears to be frozen. A bit more technically, it's because the message pump that is responsible for processing user interaction with on-screen elements is not running (it's part of your code that has been temporarily suspended until the function that you called finishes processing). This is a bit more difficult for a VB programmer to appreciate, since none of this nitty-gritty stuff is exposed in the world of VB. It's all happening behind the scenes, just like it is in a C program, but you don't normally have to deal with any of it. Occasionally, though, the abstraction leaks, and the nitty-gritty rears its ugly head. This is one of those cases.
The correct solution to this general problem, as others have hinted at, is to run lengthy operations on a background thread. This leaves your main thread (right now, the only one you have, the one your application is running on) free to continue processing user input, while the other thread can process the data and return that processed data to the main thread when it is finished. Of course, computers can't actually do more than one thing at a time, but the magic of the operating system rapidly switching between one task and another means that you can simulate this. The mechanism for doing so involves threads.
The catch comes in the fact that the VB 6 environment does not have any type of support for creating multiple threads. You only get one thread, and that's the main thread that your application runs on. If you freeze execution of that one, even temporarily, your application freezes—as you've already found out.
However, if you're already writing a C++ DLL, there's no reason you can't create multiple threads in a VB 6 app. You just have to handle everything yourself as if you were using another lower-level language like C++. Run the C++ code on a background thread, and only return its results to the main thread when it is completely finished. In the mean time, your main thread is free.
This is still quite a bit of work, though, especially if you're inexperienced when it comes to Win32 programming and the issues surrounding multiple threads. It might be easier to find a different library that supports asynchronous function calls out-of-the-box. Antagony suggests using VB's AsyncRead method. That is probably a good option; as Karl Peterson says in the linked article, it keeps everything in pure VB 6 code, which can be a real time saver as well as a boon to future maintenance programmers. The only problem is that you'll still have to process the data somehow once you obtain it. And if that's slow, you're right back where you started from…
Check out this article, which demonstrates how to asynchronously transfer large files using a little-known method in user controls.
Recently I am using clang_complete to do C++ code completion. It is good and fast for small program but too slow for my case (I am working on large code base and usually one file takes several seconds to compile), even if I used libclang, which can cache some parsed results to speedup later parsing, if I understand correctly.
Currently clang_complete will block in ClangComplete until libclang finishes parsing. Even though it starts a worker thread, main thread still repeatedly checks if user pressed CTRLC or the worker thread completes successfully. During this period, vim becomes irresponsive and thus makes this plugin hard to use.
I want to make some improvement to this behavior, for example, ClangComplete will not block, but return empty results if it takes longer than 0.2 seconds, while the thread is still running. When libclang finishes its parsing, and it detects that I am still typing the same completion word, it will popup a completion menu.
The difficulties for this is:
how to popup a menu at that time, without causing some subtle race conditions between different threads,
how does it know whether I am still typing the same completion word? I think vim itself keep track of this, because when I type something wrong, for example, std::strang instead of std::string, then I type backspace to delete the wrong ang, the completion menu will show up again. So how do I access to this internal flag?
Vimscript is single-threaded; you won't have to worry about races.
Vim will pass the base (i.e. the part of the completion word already typed / completed) into your function. Check out :help complete-functions for details and an example.
In general, your approach (assuming you're using an embedded language like Python or Perl for the multi-threading) should be feasible; however, I haven't seen something like that attempted yet.
I have a multi-threaded application that I'm debugging inside the IDE (Visual Studio 2008, Win7-64, C++).
For "debugging" purposes, I "pretend" that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the "main thread" which handles GUI and event traffic, and a second "processing" thread where work is moved off of the "main thread"). (In a "production" build there would be a single main thread, and one-or-more "processing" threads depending on the number of detected processors.)
ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may "catch" on a break point where the previous run it did not "catch" (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).
(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)
QUESTION: Is there a way to make these break points catch more "reliably"? (What influences whether a break point "catches" or not?)
I'm aware of, and NOT concerned with the following:
Source is out-of-sync with latest linked executable
Build is not "debug" (no debug symbols available)
"Clean build" is needed (debug artifacts out-of-date)
"Step Over/Into" may not work properly when another thread "breaks"
during that first thread's stepping operation
On web searches, there was a mention of possibly setting the compiler setting to "x86" and not "Any Processor" to catch breakpoints, not sure why that might matter ... ?
Finally, yes, of course, all logic "should" be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the "real" application (think "integration testing" or "systems integration").
Normally breaking is extremely reliable. Here are some things to try:
Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
You say ISO C++, does this mean you've actually switched off all microsoft extensions? I've never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.
I'm going to agree with VoidStar and other comments. I have worked with VC6, VS2005, VS2008 and VS2010 and I have debugged pretty complex multi-threaded apps with them and breakpoints have always been reliable for me.
With once exception. For projects that use DLLs, sometimes breakpoints that are set in code from a DLL do not work. This is not because VS misses the breakpoint, but instead because the debugger cannot map that line of code to an actual location in the compiled code, probably because the pdb file could not be loaded for some reason. When this happens you see a hollow red circle in the left margin of the breakpoint line instead of the full red ball. Could this be your problem?
I have not figured out why this happens sometimes, but in my experience it only happens for breakpoints in modules that are not the main project being debugged. A workaround that I use is to start the debugger from the DLL, putting the exe in the startup debug configuration for the DLL project. Another trick that sometimes helps is to have all the projects in a single solution, and have them all setup with correct references, so that with one compilation you can rebuild the whole thing.
Good luck, I hope this helps.