I have 2 process that I want to enable multithreaded communication between them.
Both process are STA because they contains a web browser control (active x).
My scenario is this:
Process 1: send a message to process 2 and wait for return
Process 2: send a message to process 1 (not as return value, a different message)
Process 1: return a result for process 2 message
Process 2: return a result for process 1 message
When I try to perform step 2 the process 2 hangs because process 1 main thread waiting for the result.
I'm using named pipes for the communication but I'm open to any other communication method ("real" communication, not shared memory).
What I'm looking for is that a new thread will be open in process 1 when the main thread (or any other thread) is waiting for response.
I have to use the main thread to perform the call because it originally initiated from the web browser control (using "object for scripting").
If there is a way to "move" the call stack of the main thread to another thread (and then return it to the main thread to comunicate with the web browser) it will be a possible solution.
You can find my code example here (VS 2010):
http://www.filedropper.com/interprocesscomunicationusingwithwebbrowser
Debugging this situation can be tricky. You need to run InterProcessComunicationUsingWithWebBrowser2 before you run InterProcessComunicationUsingWithWebBrowser, then put a break point in line 40 (return Sender.SendMessage(ProcessNamedPipes.Process2, "hello") + Guid.NewGuid().ToString("n");) in Form1.cs
I found a solution! i changed the app to be MTA and created the Browser form in a new STA thread
Related
I am currently working on a multi-client server that uses select() to handle multiple clients. However, when a client sends a message that needs heavy calculations, I have to create a a new thread using pthread_create() so that my server can remain responsive to other messages from clients. Once the calculation is done for that client, I need to be able to return a message to the client. But I am not sure how I can know if that thread is finished and how to get it's final result. Obviously I cant use pthread_join() as that blocks my server program while running that new thread. So does C offer a function that I can use to get the end result of that child thread? I would like to avoid using Global Variables as well.
You can just check if the thread has finished before joining it from the main thread (which will be non blocking)
You should get how to do it from here : How do you query a pthread to see if it is still running?
Otherwise you can probably just send back the answer from the child thread, you can pass connection information as parameter of the thread function.
If you want the child thread to wake up the thread that is waiting in select() when it has finished processing, you can use pipe() to create a pipe. The thread calling select() adds the read side of the pipe to its file descriptor set, and the child thread writes to the write side of the pipe when it has finished its work.
You can even have it send the result over the pipe, if the result isn't too large.
I have an setup with multiple (roughly 32) processes each with 2 threads. I would like to send a message from thread 0 of process A to thread 1 of process B. So, should the message be sent specifically to the thread id or to the process id. If the message is sent to the process, by default which thread will service the message?
There are lots of ways possible. Just search for IPC. For example, you could use shared memory, synchronized by a set of semaphores.
I am writing a simple multi-client server communication program using POSIX threads in C. I am creating a thread every time a new client is connected, i.e. after the accept(...) routine in main().
I have put the accept(...) and the pthread_create(...) inside a while(1) loop, so that server continues to accept clients forever. Now, where should I write the pthread_join(...) routine after a thread exits.
More Info: Inside the thread's "start routine", I have used poll() & then recv() functions, again inside a while(1) loop to continuously poll for availability of client and receive the data from client, respectively. The thread exits in following cases:
1) Either poll() returns some error event or client hangs up.
2) recv() returns a value <= 0.
Language: C
Platform: Suse Linux Enterprise Server 10.3 (x86_64)
First up starting a new thread for each client is probably wasteful and surely won't scale very far. You should try a design where a thread handles more than one client (i.e. calls poll on more than one socket). Indeed, that's what poll(2), epoll etc were designed for.
That being said, in this design you likely needn't join the threads at all. You're not mentioning any reason why the main thread would need information from a thread that finished. Put another way, there's no need for joining.
Just set them as "detached" (pthread_detach or pthread_attr_setdetachstate) and they will be cleaned up automatically when their function returns.
The problem is that pthread_join blocks the calling thread until the thread exits. This means you can't really call it and hope the thread have exited as then the main thread will not be able to do anything else until the thread have exited.
One solution is that each child thread have a flag that is polled by the main thread, and the child thread set that flag just before exiting. When the main thread notices the flag being set, it can join the child thread.
Another possible solution, is if you have e.g. pthread_tryjoin_np (which you should have since you're on a Linux system). Then the main thread in its loop can simply try to join all the child threads in a non-blocking way.
Yet another solution may be to detach the child threads. Then they will run by themselves and do not need to be joined.
Ah, the ol' clean shutdown problem.
Assuming that you may want to cleanly disconnect the server from all clients under some circumstance or other, your main thread will have to tell the client threads that they're to disconnect. So how could this be done?
One way would be to have a pipe (one per client thread) between the main thread and client thread. The client thread includes the file descriptor for that pipe in its call to poll(). That way the main thread can easily send a command to the client thread, telling it to terminate. The client thread reads the command when poll() tells it that the pipe has become ready for reading.
So your main thread can then send some sort of command through the pipe to the client thread and then call pthread_join() waiting for the client thread to tidy itself up and terminate.
Similarly another pipe (again one per client thread) can be used by the client thread to send information to the main thread. Instead of being stuck in a call to accept(), the main thread can be using poll() to wait for a new client connection and for messages from the existing client threads. A timeout on poll() also allows the main thread to do something periodically.
Welcome to the world of the actor model of concurrent programming.
Of course, if you don't need a clean shut down then you can just let threads terminate as and when they want to, and just ctrl c the program to close it...
As other people have said getting the balance of work per thread is important for efficient scaling.
I am trying to write a Teamcenter ITK program that will run as a different thread invoked from a main thread. The main thread is invoked from an action on the UI. Since the child thread takes a lot of time to complete, if I don't create the child thread and put the code in the main thread, the UI freezes for up to 10 minutes, which is not acceptable.
Both the main and child thread need to share authentication which was done by the main thread, since I am using SSO. They also need to connect to the database. Lastly, the main thread should not wait for the child thread to complete, since else the whole purpose of having the child thread will be defeated.
The code to invoke child thread is this:
handle = (HANDLE) _beginthread (submitToPublishTibcoWf, 0, &input); // create thread
do
{
sprintf(message, "Waiting %d time for 1000 milliseconds since threadReady is %d\n", i++, threadReady);
log_msg(message);
WaitForSingleObject(handle, 1000);
}
while (!threadReady);
sprintf(message, "Wait for thread to be ready over after %d tries since threadReady is %d\n", i, threadReady);
log_msg(message);
log_msg("Main thread about to exit now");
I set the threadReady = 1 global variable whenever I am about to execute the piece of code in the child thread that takes 8 minutes to run.
The problem is that the child thread is behaving weirdly after the main thread has exited, and I get this error:
Fri May 25 11:34:46 2012 : Main thread about to exit now
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Most of the child thread executes but sometimes it just crashes towards the very end.
To prevent exiting of the child thread, we can use detaching to make child process independent and not expected to join to parent.
Thus we should not join child process and after that, we have to detach from main thread:
pthread_create(th, attr, what);
pthread_detach(th);
// and never join
Also:
If you want to add some efficiency to your application, I suggest not to use exhaustive listening of observing special event of signal like threadReady. Instead use condition variables in pthread or another signaling methods like gObject.
You have some data shared between threads and it can face mutual exclusion problem and other problems such these in multi-processing or multi-threading applications can take place in. Instead try to handle this by hand of use some mechanisms like mutex or semaphore of condition variables.
I have a C application running on AIX 6.1 using Websphere MQ 6.
The high level of the application is:
Main C application spawns a seperate THREAD that does the LOOP to get message off the queue.
When CTRL-C is hit I have a shutdown hook (via signals) that elegantly sets a "thread running variable" to FALSE and the thread ends.
The problem is whenever I hit CTRL-C I get the following reason code back:
2009 - MQRC_CONNECTION_BROKEN
So even though the MQGET on Websphere MQ is currently running the "connection handle" seems to "die" when I hit CTRL-C
Do I need to declare the connection handle in the thread as volatile or static or something else?
I assumed my thread shutdown was all 100%....and this connection broken issue is causing horrible logs to be generated on MQSeries...
I have posted a similar question to mqseries.net but was just wondering if I am missing some fundamental concept when CTRL-C is hit and my shutdown hook is triggered....
Any help will be greatly appreciated
Lynton
With the POSIX thread model consider this:
For any thread that calls pthread_sigmask() and blocks SIGINT, that thread will not receive the CTRC/C. Any of threads including the main thread, that have not blocked the signal will receive it. Handling the signal is different between the parent thread and the threads or LWP's you create.
So in the main program, you call sigprocmask() to set up handling SIGINT. As you described.
All of the other threads, on their own, have to block SIGINT, by calling pthread_sigmask().