Ticket #2276 (new defect)

Opened 7 years ago

Last modified 7 years ago

We used to ship python-launcher, but we stopped.

Reported by: cjb Owned by: mstone
Priority: high Milestone: 8.2.0 (was Update.2)
Component: distro Version:
Keywords: Cc: marco, cjb, tomeu
Action Needed: Verified: no
Deployments affected: Blocked By:


build363's build.log: ---> Package python-launcher.i386 0:0.1.0-1.olpc1 set to be updated

build515's build log doesn't have any matches for "python-launcher".

It's quite possible that the package has bitrotted and needs to be brought up to date for python2.5/F7, but we really need it -- it allows each python process to avoid importing its own copy of libraries like GTK.

Could you take a look, danw? Thanks!

Change History

Changed 7 years ago by danw

  • priority changed from high to normal

marco says that while we used to ship it, we never actually set things up to *use* it. So dropping the priority, since this is really more of a feature request than a regression.

Changed 7 years ago by jg

  • priority changed from normal to high
  • milestone changed from Untriaged to Trial-2

Changed 7 years ago by danw

  • owner changed from danw to J5

reassigning build bugs back to J5

Changed 7 years ago by jg

  • cc marco, cjb added
  • milestone changed from Trial-2 to Trial-3

Changed 7 years ago by J5

We never used it because it changes the semantics of launching in which the app which actually gets launched (python-launcher) exits which confused d-bus activation. We might be able to use the concepts with the bitfrost launching stuff though.

Changed 7 years ago by mstone

  • cc mstone added

Changed 7 years ago by kimquirk

  • status changed from new to closed
  • resolution set to fixed
  • verified set

I think this can be closed as it isn't being requested or required. If we need this, please re-open with more info about what is needed exactly.

Changed 7 years ago by mstone

  • status changed from closed to reopened
  • resolution fixed deleted

We really want this because it's the most economical technique we have available with which to reduce the total memory usage and startup-time of our many python-based activities.

The design that cjb and I discussed involved integrating this into Rainbow. That work is straight-forward and does not have to be done by me; however, getting this really working blocks on #1988.

There are, however, less desirable implementations that do not block on #1988.

Changed 7 years ago by J5

  • milestone changed from Trial-3 to First Deployment, V1.0

Changed 7 years ago by jg

  • cc mstone removed
  • status changed from reopened to new
  • verified unset
  • owner changed from J5 to mstone

Michael, reassigning to you; 1988 is marked as fixed.

Is Update.2 the right milestone?

Changed 7 years ago by mstone

  • cc tomeu added

Update.2 is a good milestone. I've merged tomeu's 'faster' hack and put it in the faster branch so we can get more experience with it.

As forewarning, I think that we're going to require some kernel work in order to get decent privilege separation in the launcher (which needs to fork, then cause the uid of the child to change).

Changed 7 years ago by tomeu

Hmm, perhaps we could target for update.2 only those initializations that doesn't bring a security risk?

Michael, doing something similar to the current patch (without having a dedicated launcher process) but without importing pygtk or dbus could be acceptable?

In a later release we could implement a more complex solution that brings bigger performance improvements.

Note: See TracTickets for help on using tickets.