I have two COM projects that I built in VS-2010 and in the Debugger I can see some extra threads. Can someone tell me what Win32 Thread and RPC Callback Thread mean and where I can find information about their details. I attached some pictures from the Threads window where you can see the Call Stack, too.
I agree with Hans Passant's suggestion, these threads would be related to the Windows. Like the RPC Callback Thread in your screen shot, my understanding it was used for the inter-process communication especially for COM+ (DCOM).
Reference:
What is an RPC Callback Thread?
Related
The question is in the subject. Let me explain "why".
I am running my application on Red Hat Enterprise Linux Server 7.7. When I was checking performance using htop I found that few threads take too much of the CPU.
I added some debug logging and found that the threads with high CPU are not created in my code. So I assume that these CPU greedy threads are created in 3rd party shared libs which I am using.
So there is a question:
Say I have a thread id (17405). Is there any way to find which shared lib started this thread?
I apologize if the question is too trivial - I started work with Linux OS not long time ago.
Thank you
Actually I found solution which looks satisfactory to me.
I start gdb, attach to my process, then i can list all threads in the process "info threads", then i select thread I am interested in, and - voila - i can see the stack trace by issuing bt command.
Works I think
What tools can I use to debug a multithreaded visual c++ application? Can I get a graph or an image of the threads or detect thread errors? I have a deadlock on a EnterCriticalSection call and I can't figure out where it stems from.
I'm looking for a thread pool abstraction in Linux that provides the same level of kernel scheduler support that the Win32 thread pool provides. Specifically, I'm interested in finding a thread pool that maintains a certain number of running threads. When a running pool thread blocks on I/O, I want the thread pool to be smart enough to start another thread running.
Anyone know of anything like this for linux?
You really can't do this without OS support. There's no good way to tell that a thread is blocked on I/O. You wind up having to atomically increment a counter before each operation that might block and decrement it after. Then you need a thread to monitor that counter and create an additional thread if it's above zero. (Remove threads if they're idle more than a second or so.)
Generally speaking, it's not worth the effort. This only works so well on Windows because it's the "Windows way" and Windows is built from the ground up for it. For Linux, you should be using epoll or boost::asio. Use something that does things the "Linux way" rather than trying to make the Windows way work on non-Windows operating systems.
You can write your own wrappers that use IOCP on Windows, epoll on Linux, and so on. But these already exist, so you need not bother.
Does somebody has any idea of HT Timer in Linux?
I will be glad if someone shares some code snippets with examples of how to implement the same.
Thanks in advance
Depends on your application type.
For event-driven applications your event notification library (like libevent) should provide timer scheduling functionality.
There is also POSIX timer_create() function, that can deliver timer expiry as a signal or a callback in another thread. Latest Linux provides timerfd mechanism to deliver timer expirations through a regular file descriptor that can be registered with select()/poll()/epoll().
Here similar question with sample code for clock_gettime().
I'm preparing to write a multithread network application. At the moment I'm wondering what's the best thread pattern for my program. Whole application will handle up to 1000 descriptors (local files, network connections on various protocols and additional descriptors for timers and signals handling). Application will be optimized for Linux. Program will run on regular personal computers, so I assume, that they will have at least Pentium 4.
Here's my current idea:
One thread will handle network I/O
using epoll.
Second thread will
handle local-like I/O (disk I/O,
timers, signal handling) using epoll
Third thread
will handle UI (CLI, GTK+ or Qt)
Handling each network connection in separate thread will kill CPU because of too many context switches.
Maybe there's better way to do this?
Do you know any documents/books about designing multirhread applications? I'm looking for answers on questions like: What's the rational number of threads? etc.
You're on the right track. You want to use a thread pool pattern to handle the networking rather than one thread per network connection.
This website may also be helpful to you and lists the most common design patterns and in what situations they can be used.
http://sourcemaking.com/design_patterns/
To handle the disk I/O you might like to consider using mmap under linux. It's very fast and efficient. That way, you will let the kernel do the work and you probably won't need a separate thread for that.
I'm currently playing with Boost::asio which seems to be quite good. It uses epoll on linux. As it appears you are using a cross platform gui toolkit like Qt, then boost asio will also provide cross platform support so you will be able to use it on windows or linux. I think there might be a cross platform mmap too.