[Openembedded-architecture] Bitbake server rework
Richard Purdie
richard.purdie at linuxfoundation.org
Fri Jul 21 13:05:17 UTC 2017
On Fri, 2017-07-21 at 14:51 +0200, Martin Jansa wrote:
> On Fri, Jul 21, 2017 at 08:55:10AM +0100, Richard Purdie wrote:
> >
> > I just wanted to give people a heads up that a pretty significant
> > change in bitbake's internal behaviour has merged.
> >
> > In short, the server backend to bitbake has been reworked and
> > bitbake
> > now always forks off a "cooker" or server process (if needed) and
> > then
> > connects to it using a unix domain socket.
> >
> > The xmlrpc and process server backends are replaced with one
> > unified
> > interface where there is always a process server which can
> > optionally
> > provide an xmlrpc interface for remote connections.
> >
> > This means you get "memres" behaviour simply by setting
> > BB_SERVER_TIMEOUT to some positive value and then the cooker will
> > remain around for that length of time before unloading from memory.
> >
> > Right now, the default is 0 giving the same behaviour as before,
> > with
> > the change that the cooker is always an independent process.
> >
> > BB_SERVER_TIMEOUT being non-zero is known to break some oe-
> > selftests
> > right now, that is some we can start to address now we have the
> > code
> > baseline merged. It does seem to work well in normal use although
> > the
> > internal server resets for new connections may need optimisation
> > too.
> >
> > I do expect we may have some teething issues with this as its a
> > major
> > change to the way we've done things. I (and other bitbake
> > developers)
> > do believe this is the best way forward for the project though and
> > now
> > is the best time to merge this and get people using it. Not least,
> > it
> > replaces a load of horrible code nobody really understood with
> > something simpler and more understandable and capable. I am
> > delaying M2
> > a little to ensure we get this in now and have time to fix issues
> > before 2.4.
>
> Are there any changes needed for PRserv (or it's configuration)?
No, no changes are needed. We are seeing that server shutdown can be
slower than new clients starting in some cases though and if that
happens, you see the retry message. It should be harmless if a little
annoying on the console.
I've been trying to pin down the circumstances that happens under, it
could be PRServ is a factor (buildhistory may be too).
Cheers,
Richard
More information about the Openembedded-architecture
mailing list