+Christopher Halse Rogers
"the graphics buffers are all refcounted in the kernel, which should make (1) and (2) a non-issue." Read my 1 and 2 again.
1) is handled by reference counting in kernel correct or should be in an fictional world. Reality throws up a few spanners to this idea. Error can come about due to an allocation not being not being detected as in use by application yet. Its all timing.
Mir allocates buffer.
Mir returns buffer to client.
Application gets buffer message.
Kernel cleans up buffer because mir was the only one assocated with it at this point.
Application spits chips because it just attempted to use a buffer that does not exist any more.
Yes race condition complet ass to debug only will turn up if display server crashes at the right time and kernel does not see that buffer being sent back owns to the application. I don't want to have to be looking for race conditions.
Sorry all refcounted does not become good until application is referenced to the buffer. Before application is referenced to buffer it could go by by on Application. This is why I hate server side allocation so much. The kernel refcounted works badly for client side allocated as well. But with client side allocation only you then only have to worry about the server code handling deferfenced handles correctly. Yes client side crash still could cause mir to go splat trying to access a allocation that the kernel has nuked if mir does not check if the item its been told to display is still in existance.
Refcounted to handle without disaster requires you to check if the handle still exists by the time you get it. Application developers I don't trust that much.
Next issue here is when an object has zero reference items that have touched it yet the display server has said hey this is going to X application should kernel free or not free. Thinking application might never ever use that buffer you have sent to the application.
Server allocation being sent to client application creates impossible locations for the kernel to work out what it should do in case display server crash. Reference counting does not magically fix this. Reference counting stops allocated from being freed by all known users. When you get into the case that of the maybe users you are in trouble without coding to handle buffer being cleaned up incorrectly.
Client side is a lot less vague. Yes the client allocated yes they want it. So as long as the client remains don't attempt to clean up. Yes client sending buffer to server and dieing at exactly the same time before the reference is assigned to the server can cause some pain.
Display server coders can be judged as skilled and careful enough to build in tests into there test suite to detect client side issues. Client side coders being judged as making safe code is highly risky to user expenicence.
2) Issue I detailed is not handled by kernel. 2 is someone deciding to secure something like mer and adding a library that tracks all allocations then proceeds to destory them. This is to prevent data leaks in case of application termination. Result if there is not a clear split in allocation locations items like this kick toe big time. So resulting in nice big failures. If you don't allocate you don't trust it to remain basically.
"And (3) seems like a feature rather than a bug to me, at least for the vast majority of applications. The server has gone away; anything in the client that wants to render or receive input should block."
Its a feature in some cases a bug in another. Currently with input application can check if any is waiting if no keep on going. So input is already non blocking if application is coded to be non blocking.
Take a case of something like blender rendering up a video or someone downloading a file or many other operations. These might trigger the application to want to render something. Your response is stall. Now if the client side application is not coded well. You might have snapped a user download or something else.
You are presuming the client side application is quality. Reality you can fairly much bet against client side application being quality all the time.
Next think VNC/RDP with network lag. The ablity to disconnect an application and let it run is a highly useful feature to a render farm it also useful in some nice cases. Thin Terminals. So as a user I can disconnect a thin terminal intentionally and the applications I have running get to run until they hit the point of truly needing user intervention. So work time is not lost if a person has to move from one terminal to another.
headless has some advantages. http://xpra.org/
can operate effectively over links too slow for vnc and rdp. Because it can go headless.
Ok there is a 4 issue Christopher Halse Rogers and Daniel Stone. Using cgroups to limit and application memory allocations. How can I pull this off perfectly if you go and server side allocate stuff. Server in 1 cgroup applications in another cgroup. So they are being mesured split.
2.8+ Linux kernel will allow userspace started cgroups limiting memory. So there is no reason why a user cannot choose to run one of there graphical applications in a cgroup to kill it if it goes memory nuts.
Yes server side reallocate of some form is valid..
1) Client allocates
2) Server recevies allocate.
3) Server calls to kernel to safely reallocate this buffer to a more performance gaining location.
Where is the push back to client here. There is not one after than making the existing buffer processed and up for resuse. Also the reallocate of exactly the same size also means to cgroup maths that allocation does not have to be added to the servers memory usage.
This is why who allocates is important. Who quota of allow memory should the buffer come out of basically. If the server allocates the kernel will believe it comes from the server quota.
The does not matter who allocate is bogus. Unless you can explain to me how you will make sure the allocation will appear in the correct cgroup memory usage item. Heck in the correct /proc/(pid)/status of usage allocation.
This is where server side allocation comes appart normally. You look in /proc/pid mir/status see its grown look in application and have it appear small. Why allocation has tricked mir into doing the allocations for it.
Reporting goes wrong when you start using sever side allocation.
The 5 is Out Of Memory Killer. Allocating memory like mad could push the display server to the top of the most wanted list to the Out Of Memory Killer. Ask postgresql developers about this. They fall fowl of it all the time. Fairly much they refer to it as kill postgresql then kill everything else. This comes down to how much postgresql has to allocate under load. Number 5 again refers to status information in /proc/pid application/status being wrong. Its something that you cannot afford to be wrong.