[GRASS-dev] native WinGRASS and attribute data deadlock, next try

[Moritz Lennert]

On 04/10/07 23:28, Glynn Clements wrote:
> Moritz Lennert wrote:
> 
>> So, where should we go from here ? Is it still wiser to implement 
>> readn/writen as you suggest above ?
> 
> This is where it gets awkward.

Reading on below it actually seems quite straightforward. ;-)

> GRASS uses XDR/RPC for two purposes: libgis uses it for reading and 
> writing FP raster maps, and DBMI uses it for communication between
> the client and driver.

So we should probably thoroughly test libgis' uses of it in windows. 
What would be the best way to do this (i.e. in which 
circumstances/modules is the xdr part of libgis called) ?

[...]

> My preferred approach would be to change lib/db/dbmi_base to simply 
> not use XDR (that isn't anywhere near as much work as it might
> sound).
> 
> As the driver and client always run on the same system, it doesn't 
> matter if the protocol is platform-dependent (I have no idea what 
> Radim was thinking when he decided to use XDR for the DBMI 
> communication).

I always had the same question, but (in my ignorance) I thought that it
might make a difference if the actual database was on a different
system. If it doesn't, then let's drop xdr for DBMI (we do really need
it for libgis, I suppose ?).


> 
> The dbmi_base library uses the following functions from XDR:
> 
> xdr_char xdr_double xdr_float xdr_int xdr_short
> 
> xdr_string
> 
> xdrstdio_create
> 
> The first five all simply read/write the specified value in a fixed 
> (i.e. non-platform-dependent) format; i.e. convert to big-endian 
> order, and convert FP values to IEEE format. For DBMI, we can just
> use the host's native format, so the first five all amount to calling
>  read/write on the value.
> 
> xdr_string is slightly more complex: read/write the length (including
>  the terminating NUL) as an unsigned int, followed by the bytes.
> 
> xdrstdio_create just sets everything up so that the read/write 
> operations go through fread/fwrite (as opposed to e.g. xdrmem_create 
> which sets up for reading/writing from memory).
> 
> IOW, the actual implementation of an XDR replacement is trivial. So 
> trivial that you would just inline most of it into the 
> db__{send,recv}_* functions.
> 
> It's changing the dbmi_base library to use it which will be most of 
> the work. You would probably want separate put/get functions rather 
> than the XDR mechanism of setting the "direction" when creating the 
> XDR object and having a single function for both read and write.
> 
> E.g. db__send_int() would change from:
> 
> int db__send_int(int n) { XDR xdrs; int stat;  stat = DB_OK;  
> xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat =
> DB_PROTOCOL_ERR; xdr_end_send (&xdrs);  if (stat == DB_PROTOCOL_ERR) 
> db_protocol_error(); return stat; }
> 
> to something like:
> 
> int db__send_int(int n) { int stat = DB_OK;  if (!db__send(&n,
> sizeof(n))) stat = DB_PROTOCOL_ERR;  if (stat == DB_PROTOCOL_ERR) 
> db_protocol_error(); return stat; }
> 
> with db__send() defined as:
> 
> int db__send(void *buf, size_t size) { return writen(_send_fd, buf,
> size) == size; }
> 
> [Actually, you would probably inline writen() here, as this is the 
> only place it would be used.]
> 

I will need a while understanding this, especially understanding which 
files need replacement.

Currently we have the following files in dbmi_base (ls -1 xdr*):

xdr.h
xdr.c
xdrchar.c
xdrcolumn.c
xdrdatetime.c
xdrdouble.c
xdrfloat.c
xdrhandle.c
xdrindex.c
xdrint.c
xdrprocedure.c
xdrshort.c
xdrstring.c
xdrtable.c
xdrtoken.c
xdrvalue.c


of these only the following reference xdr.h ( grep -l xdr.h *.c)

xdr.c
xdrchar.c
xdrdouble.c
xdrfloat.c
xdrint.c
xdrprocedure.c
xdrshort.c
xdrstring.c


xdrchar.c, xdrdouble.c, xdrfloat.c, xdrint.c, xdrshort.c, xdrstring.c 
contain the functions you explain how to change above. The only place 
where they are called is in the macros.h in the same directory. I 
imagine that xdr.c and xdrprocedure.c can just go to the bin.

So "all" we need to do is create new files containing the functions 
called in macros.h according to the model you describe above.

What about the other xdr* files which do not actually directly use any 
xdr calls (xdrhandle.c, xdrindex.c, xdrtable.c, xdrtoken.c, xdrvalue.c). 
Should we just leave them as they are ? Should we rename them to avoid 
future confusion ?

Moritz