[Xapian-devel] Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

[Mark Hammond]

Olly writes:

> On Mon, Apr 02, 2007 at 12:05:44AM +1000, Mark Hammond wrote:
> > Richard writes:
> > > I've got everything working again on
> > > Linux - let us know how you do on windows.
> >
> > It's all working fine for me - thanks!  I've a few
> outstanding patches from
> > xapian-maintainer-tools/win32msvc, but I'll add them to
> bugzilla over the
> > next few days.
>
> Interesting - does "make check" currently pass for you under MSVC?
>
> I found that the WinsockInitializer mechanism just didn't work as
> it currently is in SVN for TcpClient because the TcpClient constructor
> creates the socket and passes it to initialise the parent class which
> happens before the winsock_initializer member is initialised.

It did work for me.  I'm a little confused by the above though - my patch
has the winsock initialization done via the construction of a static
module-level variable - the constructor initialized Winsock.  However, it
seems to me that TcpClient objects are always created via "new
TcpClient(...)", and the best I can tell, this is not done via the
initialization of a variable, but instead via code called via main() - so
its unclear to me how a TcpClient() was created before winsock was
initialized.

However, I really don't care enough to track this down :)  It *still* seems
to work OK for me, so that is fine.  The test results in:

apitest total: 448 tests passed, 126 failed, 11 skipped.

> The problem is that tests seem to randomly fail to connect to
> the remote
> backend, which I think must be down to timing issues with starting
> xapian-tcpsrv versus trying to connect to it.  Under Unix we carefully
> wait until xapian-tcpsrv outputs "Listening" to avoid this problem.
> Perhaps adding a short "sleep" after starting xapian-tcpsrv
> will provide
> an acceptable workaround.

I too see failures that appear related to timing issues with the stooopid
process launcher code I added, but haven't found the time to address that
yet.  A sleep() would probably work, as would redirecting the output of the
program to a unique temp filename.  The *best* solution is obviously code
that directly invokes the child process with redirected std handles, so we
can check for the "listening" string, the special 69 return value, and
otherwise work like the unix version.

Cheers,

Mark