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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
