[Gambas-user] Multi threaded apps

[Doriano Blengino]

Benoit Minisini ha scritto:
> On samedi 06 septembre 2008, Doriano Blengino wrote:
>   
>> Pino Zollo ha scritto:
>>     
>>> Alle 19:11, venerdì 5 settembre 2008, nando ha scritto:
>>>       
>>>> This thread would cease to exist when the SUB is completed.
>>>> The main thread continues processing along side this one.
>>>>
>>>> The interpreter would have to switch running threads regularly.
>>>>         
>>> I guess that there should be many instances of the interpreter, one for
>>> thread. Hope the interpreter is light enough !
>>> Very nice and usefull to have !
>>>       
>> I think the easiest way is to have an "Idle event" - an event fired
>> everytime there is nothing else to do. In the Idle event handler, one
>> can run many background jobs. May be this is already possible using a
>> timer with very short interval (zero?), but this is not the intended
>> usage of timers.
>>
>>
>> Happy coding to all,
>> Doriano Blengino
>>
>>
>>     
>
> Gambas interpreter was not designed to be multi-threaded at all.
>
> What sort of background process people want to do during their application? I 
> never had such a need.
>   
It depends on what kind of applications you develop. I speak only for 
myself but, in general, a problem arises every time you want to do some 
sort of background process where you want all the power the CPU has, but 
without sacrificing the application responsiveness to user input.

For example, I made some time ago a picture viewer able to open a disk 
directory, show thumbnails of pictures inside it, and let the user click 
on a thumbnail to view the full image. If a user selects a directory 
having thousands pictures in it, he simply cannot wait until all the 
thumbnails are made - this can take several seconds or minutes. So, 
while creating thumbnails, the program must respond to user input - the 
thumbnails creation is a background process. The program tries to create 
the thumbnails the user can see - if the user scrolls the listview down, 
the program gives up what it was doing before, and starts to analyze the 
pictures from the first item now visible in the list. If the user 
changes directory, the file list is refreshed and the whole thing restarts.
Now, this problem could be solved in gambas by implementing a loop for 
the thumbnail creation, with a WAIT inside it to let the program catch 
user input, but this reverses in some way the whole idea: the foreground 
process, in this case, would be the creation of thumbnails, expressed 
with some sort of cycle. Written like this, the program never leaves 
this cycle - until the thumbnails are finished, of course.

In another occasion, I wrote a kind of file manager (ftp client, to be 
precise), which copied files in background. When the user wanted to copy 
a file, the request was appended to a job queue; the background process 
consumed up the queue, one file at a time. Simple and clean, this is the 
beauty of background. Again, it could be done in gambas too, but 
reversing the concept.

But this is not all, about multitask. The two examples were only about 
background tasks, not true multitasking. But now the things get much 
more complicated...

Regards,
Doriano Blengino