Variable sized server replies

Alexandre Julliard julliard at winehq.org
Sat Jun 24 03:11:47 CDT 2006


"Thomas Kho" <tkho at 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:
>
> 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.

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
julliard at winehq.org



More information about the wine-devel mailing list