From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA10719 for caml-redistribution; Fri, 11 Sep 1998 19:34:30 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA14621 for ; Fri, 11 Sep 1998 18:35:41 +0200 (MET DST) Received: from welcome.disi.unige.it (welcome.disi.unige.it [130.251.61.111]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA06505 for ; Fri, 11 Sep 1998 18:35:36 +0200 (MET DST) Received: (from leroy@localhost) by welcome.disi.unige.it (8.8.3/8.6.9) id SAA10152; Fri, 11 Sep 1998 18:41:05 +0200 Message-ID: <19980911184105.B10140@welcome.disi.unige.it> Date: Fri, 11 Sep 1998 18:41:05 +0200 From: Xavier Leroy To: Friedman Roy , caml-list@inria.fr Subject: Re: socket in the windows port References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Friedman Roy on Fri, Sep 11, 1998 at 12:23:29AM +0200 Sender: weis > In looking at the code of socket.c for windows, I noticed the following > code: > /* Set sockets to synchronous mode */ > optionValue = SO_SYNCHRONOUS_NONALERT; > setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, > (char *)&optionValue, sizeof(optionValue)); > Is there a reason it is there? I'm not in front of my Windows development machine, so this is all from memory. My recollection is that setting the sockets to synchronous mode is necessary if one wants to read and write from sockets using the generic ReadFile and WriteFile system calls. This is what the libunix does, since it does not distinguish file handles and socket handles (As per the Unix programming model). > One negative aspect of this is that when > one tries to set a socket to a non blocking mode and then connect to it, > then NT returns a WSAEINVALID error code, meaning that the operation is > not allowed on that socket. I don't remember how "non-blocking mode" works under Windows. At any rate, couldn't you just use blocking I/O operations in several threads instead? Regards, - Xavier Leroy