I would appreciate some last finetuning on the patch I made to the socket tests. I kind of lost the overview in the object oriented spaghetticode (or better yet, I never got a clear insight on what exactly happens when and where) in socktest.pike.
I agree that the socktest.pike code isn't the most readable... One of the reasons is probably that it has survived since before Pike 0.4 (ie since before the module system).
I see you (or anyone else) didn't change it yet. If nobody understands it enough to fix it further, it might be faster to write it again from scratch.
I tried to emulate what is supposed to happen to drop the socket successfully, but apparently I didn't succeed completely (I still see some timeouts while running it on Solaris, although not every failure results in a timeout anymore now).
I've reenabled socketpair_ultra in a few more cases (for systems where UNIX_SOCKETS_WORKS_WITH_SHUTDOWN hasn't been set).
That's fine. As long as I don't see it appearing in the implementations I use (which is Linux, mostly); which it doesn't, I just checked. My fingers itched at sanitising the socketpair_ultra and my_socketpair functions, but since they're now excluded from the Linux implementation of Pike, my itch is gone :-).
With respect to the FreeBSD testsuite failures, I suspect they're the result of a failing write_oob in which the send() system call returns an ECONNRESET for some reason. It seems a bit silly though to insert debugging statements in the main Pike CVS just to be able to try and pinpoint the problem on FreeBSD via Pikefarm feedback. Anyone willing to provide a temporary login to a FreeBSD machine to troubleshoot this?