[GRASS-dev] v.what.rast speedup

[Glynn Clements]

Markus Neteler wrote:

> >> > You could try re-compiling the DBMI libraries with -DUSE_BUFFERED_IO
> >> > to see if that helps at all.
> >> 
> >> It makes things worse: I have killed the job after 6minutes... (DBF).
> > 
> > That implies there's a deadlock, i.e. one side is waiting for data
> > which is sitting in the other side's buffer.
> > 
> > I'm not sure how that occurs; reading from a stream should flush any
> > output streams. It would be useful if you could debug this to see
> > where it's blocking.
> 
> I am not sure how to debug such a case, I simply used gdb, waited,
> then CTRL-C and bt:

In general, you need two terminals, to show both sides, e.g.:

1.
	$ pidof v.what.rast
	$ gdb $GISBASE/bin/v.what.rast
	> attach <pid of v.what.rast process>
	> bt

2.
	$ pidof dbf
	$ gdb $GISBASE/driver/db/dbf
	> attach <pid of dbf process>
	> bt

You may need to set up PATH and LD_LIBRARY_PATH manually so that it
finds the correct binaries.

However, I don't think that it's going to tell me much in this case;
the driver is almost certainly at lib/db/dbmi_driver/driver.c:140 (the
db__recv_procnum() call), with the status code still sitting in the
send buffer.

Try the following patch:

--- lib/db/dbmi_base/xdr.c	15 Oct 2007 05:24:17 -0000	1.6
+++ lib/db/dbmi_base/xdr.c	22 Oct 2007 21:39:28 -0000
@@ -88,6 +88,9 @@
 int db__recv(void *buf, size_t size)
 {
 #if USE_STDIO
+#ifdef USE_BUFFERED_IO
+    fflush(_send);
+#endif
     return fread(buf, 1, size, _recv) == size;
 #elif USE_READN
     return readn(fileno(_recv), buf, size) == size;

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