[GRASS-dev] Some progress on Win32 attribute deadlock problem

[Glynn Clements]

benjamin.ducke at ufg.uni-kiel.de wrote:

> >> If any of you have any bright ideas, I'd be grateful to hear about them.
> >
> > My first guesses would be:
> >
> > 1. The "#ifdef __MINGW32__" portion of lib/db/dbmi_client/start.c
> > 2. The Windows port of the RPC/XDR library.
> >
> > If the behaviour is non-deterministic (i.e. you don't get exactly the
> > same behaviour from consecutive runs), I would suspect that it's
> > timing related. Checking that incomplete read/write operations are
> > correctly handled might be a good place to start.
> 
> Interesting. I've had some other folks suggest a timing/priority problem,
> too. I think we are getting closer here. I was going to look into XDR lib
> on a  hunch, too.
> How would you advice to check for incomplete read/write ops: keep a count
> of open files and compare it to the number of closed files once for every
> run through the main export loop in v.out.ogr?

No, that won't help.

I'm referring to the situation where read/write return a short count,
e.g. "write(fd, buf, count) < count". But, I've remembered that XDR
uses stdio rather than POSIX I/O, and I don't think that fread/fwrite
can return a short count (except for EOF).

According to the MSVCRT documentation, the O_NOINHERIT flag should be
used when using _dup2(), e.g.:

	_pipe(p1, 250000, _O_BINARY|_O_NOINHERIT)

Another suggestion: try changing the size passed to the _pipe()
function in dbmi_client/start.c. If that affects the tendency to
deadlock, it strongly suggests that the issue is related to the way
that a full pipe is handled.

Beyond that, the only thing which I can suggest is to instrument the
XDR code with debug code to log all I/O operations (including the data
which is read/written).

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