One thing I think we should consider early on in the planning of 1.0 is how we should to threading, and where. For an overview of threading with code examples, check out Tutorial on Threads Programming with Python.
PDF file: http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf Good ol' HTML: http://74.125.93.132/search?q=cache%3AJaEcXo0ZqncJ%3Aheather.cs.ucdavis.edu%2F~matloff%2FPython%2FPyThreads.pdf+python+threading+concepts&hl=en&gl=us Here is threading in a nutshell: Computer programs do one thing at a time, and if task A takes a long time, it will be a while before task B is executed. This works just fine for programs that are sequential in nature, but not all programs are like that. Lets say a user of Keryx is downloading a bunch of packages. Without threading, the Keryx interface will freeze until the downloads are done. Since many of the things that one would do with Keryx (downloading, searching package lists, etc.) do not need to be sequential, this is not desirable. By putting things into threads (which act like "light weight" processes), the different things Keryx is doing basically share CPU time, therefore giving the appearance of multitasking (CPUs never really do two things at a time). This would also bring us closer to the goal of the GUI being able to work on multiple projects simultaneously, even if that is not implemented until 1.0+1. Obviously we need threading somewhere in Keryx. However, this leaves the question of how things should be split into threads, and where that threading code should be. I'll explain the options for each in order, along with my opinion/bias. There might be other options, but I'm not seeing them at the moment. #1: What should be in threads? One approach would be to put individual tasks (aka download these files, search for this in the db, resolve these dependencies) in their own threads. The other approach would be to put each instance of a project into it's own thread. I think the latter approach would be the best, as it would involve less code and would not necessitate that project definition writers would have to mess with the tricky subject of threading. #2: Where should we put/implement the threads? The two options are that we ether implement threading in libkeryx (assuming we have one, and I've explained my opinion on that), or we put it in the UI code. I'm in favor of the first option. Obviously, if we did not use a libkeryx, the UI code would be the only place for it. However, this would mean that each UI that wanted to use threading would need to implement it separately, which means more code and more potential sources of bugs. Obviously the wxWidgets interface would need threading. The Apt like CLI interface would not of course. However, what if someone wanted an ncurses based interface? The person writing such an interface would have to implement threading on their own, which would be a clear violation of Don't Repeat Yourself. That's my $0.02 on the issue. What are your thoughts on the issue? If you can think of a better way of doing threading, or a reason why I might be insane, please speak up. - Douglass Clem Chief Technology Officer, Crashsystems LLC (crashsystems.net) Public Key: 37F9 E685 576A CFD3 B08C
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~keryx Post to : [email protected] Unsubscribe : https://launchpad.net/~keryx More help : https://help.launchpad.net/ListHelp
