[Gambas-user] Multithreaded Programs

[Doriano Blengino]

Benoît Minisini ha scritto:
>> 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.
>   
I don't know what web server you are speaking about, but that is not 
important - I take it for true because I know you never lie. But you are 
speaking about speed, which is not the only important thing. In fact, 
every user of gambas should know that the same program, written in C++ 
instead of gambas, could run from 20% to 1000% faster. But, by using C++ 
instead of gambas, you also loose a lot of other things. The same 
applies in the comparison event-driven vs threaded model. In a typical 
GUI program there are tenths of different events, but the user fires 
them one at a time; so it makes sense to use an event driven approach. 
But try to implement a serial (or network) protocol using events instead 
of threads. For the same event ("a packet has arrived") you have to do 
at least three or four different things, depending on what data arrived, 
and when. And if you try to set up more than one connection, things get 
more complicated. A threaded model makes this things trivial. But this 
is just an example, and I say so because of the programs I normally 
write - communications, industrial control and automation, things like 
that, often are more easily described in terms of thread and background 
processes.

Regards,
Doriano