• C

Why doesn't XtAppProcessEvent keep a Work Process running?

I'm running C/Motif on Unix (Solaris).

I have an app where I call a function which does intensive processing and can run for minutes.  This of course locked up the GUI (I'm using XtAppMainLoop).  I wanted to avoid any forks to run this lengthy function, so my solution was to embed the following code inside the function such that it got called a few times per second:
   while XtAppPending (main_app))
      XtAppProcessEvent (main_app, XtIMAll);

This worked great at freeing up the GUI main window.  However, it had an unintended side affect.  I have a work process running to display the status of the lengthy function.  The work process runs OK until the lengthy function is entered, then it freezes until the function is done.

Is there a way to keep this work process running?
Who is Participating?
grg99Connect With a Mentor Commented:
The problem may be that you're already in an event processor and you're calling yet another event processing loop.  Many GUI toolkits detect this and prevent any further events from being handled, especially repaint events.

I'd go back to using a separate thread for the computation, OR have the lengthy computation do just a bit of work, then return to the main loop.  Save just enough state so you can do another bit of work the next time around the main loop.

Kent OlsenConnect With a Mentor Data Warehouse Architect / DBACommented:

I agree with grg99's first suggestion.

You have already built the "computation intensive" function.  If you're happy with it, there's no point changing it to crudely accommodate other functions.

Simply start up a new thread and have the new thread execute the function.

Neat, quick, painless, and it should solve all of your other problems.

jimdgarAuthor Commented:
I have no experience with threads (assume you mean using pthread_create), so before I go down that road, a few questions:

1) I previously solved the "lengthy function" problem using popen to fork a separate process.  This worked fine except i/o was a pita and giving the user the ability to abort the function was tedious.  If I use pthread, does it solve these issues?  Are stdin, stdout, etc. in the Thread the same as in the main, or do I need to pipe them?
2) The quick POSIX Threads tutorial I just read says that main should wait until a thread is complete to continue (use pthread_join).  If main is waiting, doesn't this lockup the XtMainAppLoop and put me right back where I was?
3) Will a Unix thread implementation port over to Linux?  I've seen some postings which state that you must use fork on Linux.

Sorry for not answering his further questions.  

(1)  Threads will help, as i/o isnt needed then, as all global variables and file streams are shared between all threads.  So you don't have to pipe the i/o around, but you do have to ensure with a few interlocks that several threads arent trying to simultaneously read or write.
For interlocks you can use something as fancy as system mutexes or as simple as carefully set and checked flags.

(2)  No, main doesnt have to wait for a thread unless it wants to.  I think they;re referring to not exiting main() until you're sure the threads have doine everything you want them to do.

(3)  I think threads are mostly portable to Linux.  There's probably some little details that are slightly different but if you stick to simple things there should be little problem.  

jimdgarAuthor Commented:

Thanks for responding. Incidentally, I got advice (away from this board) to avoid Threads if possible. So, I stuck with the "XtAppPending" and "XtAppProcessEvent" usage and got rid of the work process. For my particular application this works fine.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.