RE: 7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-co

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


_______________________________________________
Xapian-devel mailing list
Xapian-devellists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-devel