[haiku-development] Re: graphics server
- From: James Taylor <james.dewey.taylor@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 7 Dec 2011 05:56:04 -0600
The way it's currently configured is that storage is separate from the
server itself so should the server crash, the data should still be
valid unless the server crashed due to invalid data which when it
recovers it can deal with appropriately. The clients can continue to
write to the buffers without even knowing the server has crashed
(unless the buffers are full which is a different problem entirely).
So in short: no, the clients are protected as well from
graphics_server crashes. Given that the buffers aren't full when the
server crashes, if the monitor team is set to a real time priority,
theoretically nothing (or very little) else will be written to the
buffers by the time the server comes back up and can process them. If
nothing else I suppose the clients could be halted until the server is
ready for them, but that's a little extreme.
As far as the direct rendering issue, I don't think it would be that
difficult to switch over to that later. I'd just like to see it
working first.
There are still some considerations I'm working on which will greatly
affect this project in the future, but until those come to fruition
I'm just trying to stick to the original design and make it work.
As far as app_server integration, I've had a similar discussion
already and my take on it is that the app_server can still manage
windows and do it's other work without any graphics code being present
in the app_server itself. Separating the graphics code from the
app_server will allow for easier development and debugging as the
graphics server matures, but nothing is keeping it from being
reintegrated later should it be necessary. I don't see any performance
hits as a result of there not being any integration.
Regards
On 12/7/11, Clemens <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> On Sat, 03 Dec 2011 17:16:34 +1300, James Taylor
> <james.dewey.taylor@xxxxxxxxx> wrote:
>
>> Questions / comments / suggestions / assistance is/are always welcome!
>
> While I think in general its a good idea, I think the changes should be
> done directly in the current app_server. Writing a new server seems to be
> a lot of work.
>
> What is needed is basically the ability to restart the app_server. This
> requires that a new instance of the app_server is able to reconnect to the
> still running clients. This means one component has to store informations
> about the client windows, their port, size, position, tab position, S&T
> configuration, etc. This information is needed to restore all windows
> after a restart. Having another process running that has to be updated
> about everything is certainly a performance issue but maybe there are some
> tricks to avoid unnecessary communication? For example, store all info
> directly on client side.
>
> A interesting use case for a restart-able app_server would be that a
> composite app_server could be replaced by the current app_server in case
> the memory runs low.
>
> This everything sounds nice but I have one other concern. Stippi already
> suggested that the drawing in a window should be done on client side which
> certainly is a good idea. The question is if an accelerator or the
> graphics_server crashes, all the drawing clients are dead too?
>
> Regards,
> Clemens
>
>
Other related posts:
