Could you please take a look on what I found out (see my other post)?
Which exactly?
The "Solved: bug in tcp/ip on windows" one (well, there is not much code
actually... I originally thought I'd include the std::set rewrite of
os.cc, but I did not since it won't link).
There is no problem in Open.socket - in fact, the backLog parameter
*can* be specified to Open.socket's meth listen and is passed correctly
to OS.listen.
Yes, just after I sent the mail I remembered that Open.socket has the
method listen.
Well, I read your other mail in which you explain this just after I'd
sent this :-)
I just have a feeling that on Windows you can not get past
the WinSock1's SOMAXCONN=5 limit.
Indeed, the SOMAXCONN used to be set to 5 in cygwin, but from a cvs log
from year 2003 I see that they switched to 0x7fffffff.
So I would say that cygwin is not introducing the limitation.
I don't think that it's a Cygwin limitation. Mozart does not rely on
Cygwin binaries, anyway - it includes winsock.h and links winsock
directly (see platform/emulator/wsock.hh). But it includes and links
winsock1, not winsock2. Winsock.h defines SOMAXCONN = 5, Winsock2.h
defines SOMAXCONN=0x7fffffff.
Anyway, the socket code in os.cc for win32 is not good. For example,
SOCKET (defined as UINT_PTR) is silently converted to int - this will
introduce problems when someone will be porting Mozart to Win64 (note
that e.g. socket() returns SOCKET, not int, on Windows). And IMHO the
usage of fd_set is a bad idea too.
Cheers,
Filip
_________________________________________________________________________________
mozart-hackers mailing list [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
