From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p72KfwCM025397 for ; Tue, 2 Aug 2011 22:41:58 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDANVgOE5RZ90xkWdsb2JhbABChEeTWo5TdBQBAQEBCQsLBxQDIoFAAQEBAQMjERUlCxACAQgOCgICBgMdAgICMBMCAgENAQEEDg0Kh1wCrlqRLoErhAcxXwSSe5Bk X-IronPort-AV: E=Sophos;i="4.67,307,1309730400"; d="scan'208";a="114800950" Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]) by mail1-smtp-roc.national.inria.fr with ESMTP; 02 Aug 2011 22:41:46 +0200 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110802204145.NCUC5301.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Tue, 2 Aug 2011 21:41:45 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110802204145.PTQS25656.aamtaout04-winn.ispmail.ntl.com@romulus.metastack.com>; Tue, 2 Aug 2011 21:41:45 +0100 Received: from remus.metastack.local ([172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p72Kffkd026275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Aug 2011 21:41:41 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 21:41:41 +0100 From: David Allsopp To: "'Gerd Stolpmann'" CC: "'OCaml List'" Thread-Topic: [Caml-list] Writing to a blocked socket Thread-Index: AcxRNTAmE9oUysB1TgqqvacnfYn7hQACwumAAAQFLPAAAQtvYA== Date: Tue, 2 Aug 2011 20:41:40 +0000 Message-ID: References: <000101cc5135$e1f1ab90$a5d502b0$@metastack.com> <1312312561.6236.307.camel@thinkpad> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.7] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=40hZHaDki8MA:10 a=O5OQiGhyCJMA:10 a=cTs9vV391PwA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=1XWaLZrsAAAA:8 a=ZOzjf2MOAAAA:8 a=CjxXgO3LAAAA:8 a=C_JTo8D0nDq7rLshBZUA:9 a=3Y9dZENp7LSloWCt-R4A:7 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by walapai.inria.fr id p72KfwCM025397 Subject: RE: [Caml-list] Writing to a blocked socket I just translated that OCaml example to C and it works correctly under Windows which suggests it's a bug in OCaml... so I'll attach that ML file to a Mantis report, instead! David Allsopp wrote: > Gerd Stolpmann wrote: > > Am Dienstag, den 02.08.2011, 18:01 +0100 schrieb David Allsopp: > > > I don't seem to be able to ask Google this in a way which will give > > > me a reasonable answer! > > > > > > In the same process, if you have one thread blocked on a [recv] > > > operation on a socket, under Unix another thread can still write to > > > the socket. Under Windows, however, the call to [send] blocks > > > because there's another thread blocked on a [recv] to the same > > > socket. Are there any options that can be set to change that > > > behaviour or is that just "the way it is" and the application has to > > > be coded using [select] > > instead? > > > > Really? This does not make sense at all. It's quite normal that one > > direction is blocked, and the other not. Are you sure about your > > observation? > > Seems to be, from the attached - important bit is on the last 10 lines - > the function readThread is spawned in a thread of its own and then the > loop below reads input and sends each line down the socket. > > Compiled with: > > ocamlfind ocamlopt -o foo -thread -package unix,threads -linkpkg Foo.ml > > and then executed as: > > ./foo www.google.com > > I enter: > > GET / HTTP/1.0 > > followed by two new lines... on Linux I get a response from Google, on > Windows it hangs after the first line. 3.12.0 (and 3.10.1 on an old > machine) all behaving the same way. > > David > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs