[maemo-developers] Re: Troubleshooting .desktop and .service file
Hi, On Mon, 27 Nov 2006 18:29:12 +0200, Eero Tamminen wrote: Hi, ext Danny Milosavljevic wrote: (One of the benefits of D-BUS is that other programs don't need to know whether your app is running, they can just send messages to it with D-BUS auto-invocation flag and D-BUS takes care that only one instance of your application is running.) If you call that an advantage... It usually breaks one of the oldest and best UNIX conventions: that the process blocks the caller until the task is done. I think you are a bit confused. Nobody's removed good ol' exec from the libc, so nothing's broken. :-) Hmm, yeah, but I meant it in a different way. I mean waitpid() won't do anything sensitive/useful anymore on gui programs. (And I gave an example to that.) Maybe I'm just a too old-fashioned UNIX-head, seeing that the nicest response was yours, and the worst response from someone else was never mail me anymore (_that_ was weird... I mean, really weird. Must be some kind of taboo he wasn't supposed to talk about ;)). Then again, it doesn't matter for viewer programs like firefox and book readers and most of the stuff used when on the Nokia 770, so don't get me wrong. I just wanted to illuminate the other side for completeness sake (in the bigger picture of all UNIX computers). Whether the D-BUS call is asynchronous or synchronous is controlled with a flag used when sending the message. (in CORBA everything is by default synchronous because it's used mainly for remote procedure calls whereas D-BUS is used more for delivering events and events are usually async) Good to know :) To place it in technical terms: I think that dbus activation doesn't allow passing a channel to the existing process, in order that the existing process could use it to signal that it is done with the task later. Seems that having a process-oriented view is really unusual this year... strange o_O You know on desktop when you want to have another browser window, you run Firefox which checks whether there's already a Firefox running and then sends a message to that so that it opens another window. Yes, even that already breaks my model (the new process should block until I closed the new window again, basically react as if it were not using the singleton-process optimization) - and its arguably a very popular program, so I guess times are just changing... Sure, it already saves some time, but more is saved if you don't need to start Firefox (or any other app) in the first place, just send the message to the already running process and D-BUS is the one checking whether something already runs... Yes, I know that as an optimization on an embedded platform this makes sense. I'm just a person that is way too used to synchronous batch scripts, so just ignore me... ;) cheers, Danny ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Troubleshooting .desktop and .service file
Hi, ext Danny Milosavljevic wrote: (One of the benefits of D-BUS is that other programs don't need to know whether your app is running, they can just send messages to it with D-BUS auto-invocation flag and D-BUS takes care that only one instance of your application is running.) If you call that an advantage... It usually breaks one of the oldest and best UNIX conventions: that the process blocks the caller until the task is done. I think you are a bit confused. Nobody's removed good ol' exec from the libc, so nothing's broken. :-) Whether the D-BUS call is asynchronous or synchronous is controlled with a flag used when sending the message. (in CORBA everything is by default synchronous because it's used mainly for remote procedure calls whereas D-BUS is used more for delivering events and events are usually async) You know on desktop when you want to have another browser window, you run Firefox which checks whether there's already a Firefox running and then sends a message to that so that it opens another window. Sure, it already saves some time, but more is saved if you don't need to start Firefox (or any other app) in the first place, just send the message to the already running process and D-BUS is the one checking whether something already runs... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Troubleshooting .desktop and .service file
Hi, On Thu, 23 Nov 2006 15:11:59 +0200, Eero Tamminen wrote: [...] (One of the benefits of D-BUS is that other programs don't need to know whether your app is running, they can just send messages to it with D-BUS auto-invocation flag and D-BUS takes care that only one instance of your application is running.) If you call that an advantage... It usually breaks one of the oldest and best UNIX conventions: that the process blocks the caller until the task is done. I usually cite the gedit example: 1. gedit blahblah.c 2. export SVN_EDITOR=gedit 3. svn ci 4. gedit opens a tab for you to enter the commit message, while leaving the tab blahblah.c open 5. you type your commit message 6. you close just the tab with the commit message 7. svn ci STILL hangs 8. you continue editing blahblah.c, hell breaks loose This is one of the most horrible blunders I've ever seen (breaking an _operating system_ behaviour assumption is about as bad as it gets). Then again, maybe its all in my mind :) And I do see that maybe the memory overhead of having a wait-until-master-is-done process that blocks until 6. happens may be too much for an _embedded_ platform. So don't take that as a condemnation, but just a in a perfect world statement. And I also see that win32 users have no problem with this behaviour, since for them it has always been that way (leading to about zero scriptability without resorting to hacks like EnumWindows) cheers, Danny ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
