RE: [CapROS-devel] rendering server stability (was: thread migration vs. dynamic link libraries)

[Christopher N. <paradox@BBHC.ORG>]

> Christopher Nelson wrote:
> > Although, another thing to think
> > about is that: if your graphics driver dies and your graphics=20
> > rendering server stays up, does it matter?
>=20
> Yes. Graphics drivers have only state that is easily reconstructable.
> If a driver dies, reload it and redraw the screen. If it dies=20
> again within a short time, reload an unaccelerated driver.

True, but the point was if the driver or the rendering server are dead,
either way you have no display.  Having the driver local to the
rendering system has such a performance impact that it seems worth it to
pull the driver into the same confinement space as the rendering server.


I wonder what the best option for recovery of a rendering server would
be?  Since that server might be authoritative about the graphic state of
each application, you couldn't really trust apps to re-inform the new
server (the one rebuilt after the previous one died).  They'd have to go
through the whole process of building their contexts again.  You have
the additional problem of re-introducing the apps to the server.

Perhaps you have a third party that serves as the original introducer.
When the rendering server dies, it reloads it and then performs
introductions again.  That would be a reasonably simple object, so it
shouldn't be hard to make it robust.

-=3D{C}=3D-