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

[Moritz Lennert]

Thanks for the help, Glynn.

On 18/09/07 21:38, Glynn Clements wrote:
> The first things which spring to mind are:
> 
> 1. There needs to be a single log file for each process, i.e. one for
> the client, one for the driver. It should be possible to display the
> files side-by-side and match each "write" from the client with the
> corresponding "read" from the driver and vice-versa.

As I said, I'm not sure I understand xdr enough to grasp 
everything...(nor C for that matter).

Just to make sure I do grasp enought to go on:

We have two streams (*1 and *2) and in each stream we have 'puts' and 
'gets'. Thus, if you look at putlong1.txt and getlong1.txt you see the 
corresponding writes and reads. However, in each stream it is either 
longs or bytes that are moved and I separated these. I will try to 
rather create "putstream1", "getstream1" logs which mix bytes and longs.

Is this what you mean ?

> 
> 2. The debug code needs to call fflush() after each record. Otherwise,
> data will be missing from the end of the file if the process
> terminates abnormally (see getlong1.txt). Moreover, the part which is
> missing is likely to be the most useful.

I thought the setbuf(debug, NULL); took care of that. Will add fflush().

> 
> 3. The actual data which is read or written should be included in the
> log entry.
> 

Isn't this what is in the buffer= field ?

For longs we have

xdrstdio_getlong(xdrs, lp)
	XDR *xdrs;
	register long *lp;

So lp points to the value, or ?

I have

fprintf(debug, "\tbuffer = %x", *lp)

which I adapted from Benjamin's code:

fprintf ( stderr, "\t addr (%i); new val = %i.\n", lp, *lp );

Should this be &lp instead of *lp ?

For bytes we have:

xdrstdio_getbytes(xdrs, addr, len)
	XDR *xdrs;
	caddr_t addr;
	u_int len;

So here, addr is the address of the value, or ? How do I access the 
actual value ?

Moritz