In protocol.def, the get_startup_info request declares two VARARGS as replies. Unless I've mistaken, replies are limited to one VARARG that the server call writes into preallocated data, right?
That leads me to my next question: I'm currently working on moving menus into the server (see http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/ for a series of patches that moves most menu data into the server. Most logic is still on the client, but it's still surprisingly snappy.) If you look at http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/10-server-mii, my problem is that I don't know the size of the data that the server is going to return and my current hack is to set a hard upper limit.
I can think of two ways to tackle this:
1. Do a server call before hand to request the size of the data to be returned. This has the overhead of the additional call, but doesn't increase the complexity of the server itself.
2. Instead of preallocating memory for the variable reply, have the request mechanism allocate it (like it does on the server end for variable sized data in the request). This also adds complexity as the reply would be callee-allocated, caller-freed (or perhaps we could take advantage of SERVER_END_REQ?). However, it seems kind of natural to have the request process parallel the reply process.
Is there another alterative? Any comments on which approach is better?
Thomas Kho
"Thomas Kho" tkho@ucla.edu writes:
In protocol.def, the get_startup_info request declares two VARARGS as replies. Unless I've mistaken, replies are limited to one VARARG that the server call writes into preallocated data, right?
There's one block of data, but it can contain multiple things, that's why you can have multiple VARARGs as long as there's a way to determine their length.
I can think of two ways to tackle this:
- Do a server call before hand to request the size of the data to be
returned. This has the overhead of the additional call, but doesn't increase the complexity of the server itself.
- Instead of preallocating memory for the variable reply, have the
request mechanism allocate it (like it does on the server end for variable sized data in the request). This also adds complexity as the reply would be callee-allocated, caller-freed (or perhaps we could take advantage of SERVER_END_REQ?). However, it seems kind of natural to have the request process parallel the reply process.
You cannot allocate memory while making a server call. Allocating memory on the client requires locking and possibly waiting on other threads, and you can't do that in the middle of a server call.
Is there another alterative? Any comments on which approach is better?
The standard way is to allocate a reasonably sized buffer, perform the call, and if it returns a buffer overflow increase the allocated size and retry. Check the get_message call for an example.
-
Alexandre Julliard -
Thomas Kho