Re: glib: processing events in multiple threads

[richard boaz <ivor boaz gmail com>]

[...]

I've heard from quite a few people in particular in the GNOME camp who
believe that everything should be asynchronous and that multithreading
is evil.

i don't know who these GNOME people are (very short?), but going with "multi-threading is evil" is an unbelievable statement: i'm gobsmacked.  (and the hardware guys wonder why we're such idiots.)  all those extra CPU's are only intended for multiple app execution and not to be used simultaneously by the same program where possible?  i can only conclude one thing here: it must be simply too difficult for them to implement.

in some vain attempt (pun intended) to restore some street cred, i offer up a different "attitude" a programmer can have where hardware advances are concerned and how these can be exploited to maximum benefit.

what my GUI program is required to do, very briefly, is to read any number of multiple files sitting on disk, each to be displayed on a separate line (seismic data files).  where this is all multi-threaded in the following manner:

• at start-up, query the computer to determine the number of CPU's available to my program
  
• on request to display data files, start a separate thread to:
• place all files to display on a single Q
• start up numCPUs threads, where each thread queries the Q (call is mutexed) for the work details, until nothing left on Q
• return to display for rendering

and what this means is: as hardware advances and more and more CPU's become available, because of this design, program execution will get faster and faster without one line of code having to be adjusted in the future.  i don't even need to recompile.

and this is just one example of how i maximize having multiple CPU's available to me.  the possibilities become endless when this concept is wholly embraced, as it should be.  do not be afraid...

To be more specific: what I wanted to avoid was the need to protect data
with mutices by ensuring that the only code ever touching it is from the
same thread. That is easier to enforce than correct mutex locking.

this, of course, comes down to your requirements' details.  only one recommendation here: when using mutexes, make sure that you surround absolutely the fewest number of lines possible to guarantee single access.

good luck, make it fun, because it is.

richard