Gordon Tyler пишет: > On 5/3/2011 3:55 PM, Alexander Belchenko wrote: >> For all bzr operations, the most often used by explorer is getting >> status of working tree, -- start new separate process for each bzr >> location. That process works as server and can talk with any number >> of clients via IPC mechanism (I'm thinking about using >> cross-platform QLocalSocket/QLocalServer from PyQt4 if that matters). > >> Using one process per bzr location is inspired by Google Chrome >> architecture (as I understand it). This approach has several pros >> and some cons. This process might fail/segfault/whatever without >> affecting the GUI process. Therefore we need another global process >> to watch worker processes and if needed restart the crashed ones. I >> think it will be nice to adapt ideas from bzr-service plugin for >> such watcher. Or maybe add that process to AutoRun as TBZR does >> (does Ubuntu/Linux have some sort of autorun?). > > Do you want to have these server processes shared by multiple bzr > explorer and qbzr client processes? That does deviate from the Chrome > model. Chrome has one parent process that manages the GUI and launches > child processes for each host? that it communicates with. Each tab in > each window is also a separate process. However, none of these persist > past the lifetime of the parent process. When you close the last > Chrome window, all Chrome processes die. > > I'm very wary of daemon/background processes that do not have a well > defined lifecycle.
That's a good question. Yes, I need server process for each active bzr location to be shared between multiple qbzr / explorer process, so only one bzr process working with one local or remote location. When all client processes quit then server process should become inactive (i.e. stop executing bzr operations) and die after some amount of time (can't say yet how long). I would not kill server right after the last client quits because it could be needed very soon by another fresh client and having the server ready-to-use and warm means we can have faster startup time for new-client-invoked-not-very-long-after. That's in theory. In practice anything can happens, some client processes can die without notifying the server about disconnect, and any shit can happen. So we will need to use some heartbeat signal between interacting processes. But this inevitable will increase the complexity of this approach, and I'm not positive. Of course, in much simpler implementation server should just die when last client quits. But perhaps the most important point for me here anyway: server should automatically become inactive after some amount of time when there is no commands/requests from clients. Inactive means stop actively crawling bzr tree for changes. Actually I don't want them to crawl the locations at all, but instead use FileSystem watchers (like inotify, PyQt4 has the handy and cross-platform one) over key bzr files to know when something changed and need update of status cache. That means when user run some operation in the console that bypass our server process we anyway will be notified about need to refresh. Also I seriously think about "cheating" here and update cache based on the set of files used in the last bzr operation. I.e. after qcommit the status cache can be immediately updated with the list of committed files and status cache may think that all those files now "clean". In the same time we start real bzr iter_changes() cycle to get the real status of the tree. But until it finishes server already can send to explorer new "calculated" state of the tree, and then send "real" state of the tree when iter_changes() finishes. That's why I need one server process per location and all operation should go through it (or at least q-dialogs should notify server about the changes they made) -- this is way for "cheating" and make explorer "feels faster", in my opinion. Overall goal of my client-servers madness is to improve the stability of explorer and make it feels faster than command-line bzr. Hope that makes sense. (I was very impressed by one lightning talk at UDS-M Thursday or Fridays Plenary given by the man I don't remember his name unfortunately :-( about speed up the applications. Unfortunately when he started to talk about caching and "cheating" in chrome and git his 5 minutes ran out, and I haven't chance to talk with him later. Does anybody know who he is? I haven't found the video for those lightning talks. Anybody?) -- All the dude wanted was his rug back _______________________________________________ Mailing list: https://launchpad.net/~bzr-explorer-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~bzr-explorer-dev More help : https://help.launchpad.net/ListHelp
