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

[Glynn Clements]

Moritz Lennert 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 ?

That's part of it.

There are two processes, the client and driver, connected by a pair of
pipes. Each process has a descriptor for the write end of one pipe and
the read end of another.

There should be one log file per process, containing both reads and
writes. If the log files are viewed side by side, you would expect to
see e.g.:

	client				driver

	putlong  STREAM2 4 bytes	getlong  STREAM1 4 bytes
	getbytes STREAM1 99 bytes	putbytes STREAM2 99 bytes
	...

Each process will need to use a different name for its logfile.

> > 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().

Hmm; the setbuf() should suffice. There may be other reasons why
getlong1.txt was truncated, e.g. both processes writing to the same
log file.

> > 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 ?

No, this part is okay.

> 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 ?

	int i;
	for (i = 0; i < len; i++)
		fprintf(debug, "%02x ", ((unsigned char *)addr)[i]);

-- 
Glynn Clements <glynn at gclements.plus.com>