l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd IPC (client side)


From: Niels Möller
Subject: Re: Hurd IPC (client side)
Date: 04 Nov 2002 23:23:39 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

address@hidden (Neal H. Walfield) writes:

> This can of course be abstracted a bit so we do not have to code this
> type of stub for every rpc.

I won't pretend to understand the RPC_GEN macros, but to me it seems
by far simplest to pass the complete handle (i.e. <threadid, local
handle> to the stub function, packed either into an integer, or as a
struct passed by value.

If at all possible, avoid using preprocessor tricks for this. It
breaks function pointers, and obscurer constructions like

  (isdir ? rmdir : unlink)(name);

and probably other more subtle things too (for example, I've seen
problems with nested function and macro calls that trigger the cpp
hack that avoids infinite recursion by not sometimes expanding macros
on the righthand side of a definition. Sorry I don't remember the
details well enough to write up an example).

You could argue that those construstions aren't needed, but I think
it's bad to gratiously restrict what parts of the C language can be
applied to the rpc functions. (I know there are several examples of
glibc "functions" that are in fact clever macros, with the same
resulting breakage. I dislike that too, I just hope there are some
good reason for each particular case).

/Niels




reply via email to

[Prev in Thread] Current Thread [Next in Thread]