[Gambas-user] Multithreaded Programs

[Benoît Minisini]

> Werner ha scritto:
> > Doriano Blengino wrote:
> >> Benoît Minisini ha scritto:
> >>>> I pretty much agree.
> >>>> Gambas as well as other RAD languages are very good for GUI
> >>>> programming, and generally for not CPU intensive purposes.
> >>>> If you really need speed, use libraries written with C/C++ or similar.
> >>>> BUT it would be very nice if Gambas could handle most things so
> >>>> quickly that you don't need to use C/C++.
> >>>>
> >>>> Maybe Gambas could launch multiple interpreters to enable
> >>>>  multi-threading..? But I think you have already considered and
> >>>> discarded that idea...
> >>>>
> >>>> Maybe interpreter itself should use multi-threading?
> >>>> Although I don't know is there yet any good way to do that, meaning
> >>>> without installing TBB or similar to enable
> >>>> easy using like parallel_for, parallel_loop etc.
> >>>>
> >>>> Jussi
> >>>
> >>> I don't like doing that, but hey, here is an authoritative argument.
> >>> :-)
> >>>
> >>> "A computer is a state machine. Threads are for people who can't
> >>> program state machines." - Alan Cox.
> >>
> >> "A computer is made of flip-flops (the very basic unit of memory). High
> >> level languages are for people who don't understand computers - those
> >> who understand them are perfectly happy with punched paper tapes and
> >> machine-level languages" - Doriano Blengino.
> >>
> >> Without multi-threading and multi-tasking there would not be computers
> >> as we know them. Full stop. This is not to say that gambas should have
> >> multi-threading, nor that Alan Cox is stupid. But that affirmation is.
> >> More on this, if requested.
> >>
> >> Regards,
> >
> > Surely Alan Cox had meant that to be understood with a nudge and a wink.
> > :-) Multi - threading opens a whole can of worms. Gambas 2 is rock solid
> > and if there has to be a choice between robustness and performance I take
> > the former any time.
> 
> Yes, agreed to all. Nudge and wink should be applied to my sentence too,
> which was ironic.
> True that multi-threading brings more problems - compilers do, oop does,
> java does; every advancing step in every field brings new problems, but
> also opens new possibilities. The task is to retain the new
> possibilities, and get rid of problems. Once you have new possibilities,
> you can choose whether to use them or not.
> And I agree even on gambas: if, by introducing multithreading, stability
> would suffer, then it is better to avoid threading. But this is not the
> question. Benoit said that he does not find a reason to use threads in
> GUI applications; the same about background processing. I don't see what
> have these GUI applications so special or so different from other ones.
> They are applications which, instead of sending results to files, send
> results to the screen. This is all. If I wanted to write a web server
> like Apache, but with a nice GUI and using Gambas, I would feel the lack
> of threading. Threads can simplify a lot certain kinds of problems - and
> can mess up other kinds of problems.
> 
> Regards,
> Doriano
> 

OK, but you should not take the example of web servers : the fastest web 
servers I know do not use threading nor processes, but event-driven 
programming around select() (or equivalent). As the gambas interpreter does.

Regards,

-- 
Benoît Minisini