This has been a long thread about threads ;-) I myself have been using a quite different aproach for a long time. Basically devide everything in ordinary unix-process. Have them talk to one another over a software buss. I have been using spread (www.spread.org) a lot but there are others (rabbitmq or zeromq). In this way you focus on events from processes and protocols between processes. This works as a charm. In Unix it is very easy to have a process connect to the software buss, and then fork. Try this. I think i can prommise that you wont miss threads. But you will have to invent a good protocol instead... /gh 2013-04-30 12:52, Tristan Van Berkom skrev: > On Tue, Apr 30, 2013 at 8:26 PM, richard boaz <ivor.boaz@xxxxxxxxx> wrote: >> >>> [...] >>> 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. > > I should mention this, because this seems to be a misinterpretation of > something I probably mentioned to Patrick myself. > > Now, there are probably a multitude of reasons for implementing an > asynchronous API, but let's stick to two very popular and probable > reasons: > > a.) The actual work is done in another process, which means generally > that calling an Async API consists of writing some bytes to a socket > (D-Bus most popularly) and adding a file descriptor to a poll() call, > awaiting your reply. > > b.) The actual work is CPU intensive, and probably already executed > as a separate thread or process. > > Now, let's say you already have access to an Async API, is there any > reason, other than the desire to play with fire, to actually execute the > Sync API *in a separate thread* manually ? > > I know this sounds like a ridiculous question, but people have been doing > just that, and this is the kind of thing I would like to discourage; i.e. > playing with threads when it is absolutely uncalled for. > > The temptation to do this stems from the apparent simplicity of calling > a Sync variant of an Async API, coupled with overconfidence of > playing with threads manually (which honestly, should be left to the > grown-ups, no offence intended to anyone really, but threading correctly > is just not trivial). > > Basically, for D-Bus at least, a Sync variant of a method call is a matter of: > > o Creating an isolated GMainContext/GMainLoop (isolated in the sense > that the only GSource which can occur while running the encapsulated > mainloop is the D-Bus method reply... *everything* is blocked while > making a synchronous D-Bus method call). > > o Issuing an Async call > > o Waiting for only the Async method call to return in encapsulated > main context > > o Collecting the return value when the call completes (or times out) > and destroying > the temporary GMainLoop & GMainContext. > > So essentially, if there is an Async variant of a D-Bus method, the Sync variant > is only a way to call the Async variant of the same API and block execution. > > But, we run into situations (like in EDS) where the user facing APIs never call > the Async D-Bus methods under the hood, but instead run a thread, and call the > Sync method *from a thread*, where it will essentially just block > while performing > a method call, not buying you any cycles on your separate CPU/cores, but adding > a lot of complexity to your code. > > I hope this clarifies things a bit, if there are Async APIs, it's > better to just use > them, if you have CPU intensive code to run, then you have justification for > threading, of course, by all means run that workload in another thread. > > Cheers, > -Tristan > >> >> 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 >> >> _______________________________________________ >> gtk-list mailing list >> gtk-list@xxxxxxxxx >> https://mail.gnome.org/mailman/listinfo/gtk-list >> > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list > -- Göran Hasse Raditex AB email: gorhas@xxxxxxxxxx mob: 070 - 5530148 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
