Hi, On Fri, 17 Nov 2006, Derek Smithies wrote: > > O.k, now here is the challenge. I have laid out my solution. > > Would the no threads people like to lay out their solution? > and here is the second challenge. Have you ever used a gui to do something, and you hit "go" (or whatever) and thing sits there totally unresponsive for 2 minutes whilte it does it's thing, and then the gui comes back to life? After 2 minutes of ignoring all user input, it finally starts to resspond
This is clearly poor programming. The writer of the gui has done everything in one thread. The main window thread which handles events is also used to do the 2 minute long calculation. A better way would be to separate the program into two distinct parts, one to handle gui stuff, and one to do the work. Each part is a separate thread. Yes, the second part could be a separate program which communicates with the first part via pipes/sockets/ipc. However, the range of variables that the gui wants to send to the action part is quite large, and the types of response so variable that "simpler" approach is to put everything into one executable with threads.. Yes yes, in some occasions, fork would do the job nicely. If there are only a couple of variables to transfer between the two processes, and the mechanism to interrupt the 2 minute process is simple, use fork. Sadly, I do not think that mmap, fork etc will help here, one is required to have threads... Certainly, having written CPhone, a H.323 video/voice gui, threads were definately necessary. Gnomemeeting/Ekiga uses threads also... In my view, threads are, at times, the correct way to solve a problem. They cannot be eliminated from a programers vocabularly. threads can be replaced by mmap/fork etc. Sometimes. threads can be a nightmare to get right. gdb is often not very helpful. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
