From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 83441BBAF for ; Thu, 17 Jun 2010 03:31:02 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4BADEYGUzdx9kLkWdsb2JhbACebxUBAQEBCQsKBxEFFwa/LIUaBA X-IronPort-AV: E=Sophos;i="4.53,428,1272837600"; d="scan'208";a="53284498" Received: from ajax.nicta.com.au ([221.199.217.11]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 17 Jun 2010 03:30:48 +0200 Received: from atp-mbx1.it.nicta.com.au ([221.199.216.123] helo=atp-mbx1.in.nicta.com.au) by ajax.nicta.com.au with esmtp (Exim 4.69) (envelope-from ) id 1OP3wK-0002EU-QJ for caml-list@yquem.inria.fr; Thu, 17 Jun 2010 11:30:45 +1000 Received: from atp-mbx1.in.nicta.com.au ([221.199.216.123]) by atp-mbx1.in.nicta.com.au ([221.199.216.123]) with mapi; Thu, 17 Jun 2010 11:30:41 +1000 From: Paul Steckler To: "caml-list@yquem.inria.fr" Date: Thu, 17 Jun 2010 11:30:40 +1000 Subject: [Caml-list] Re: Unix.send blocks Thread-Topic: [Caml-list] Re: Unix.send blocks Thread-Index: AQHLDbyyFOS1s/4PqU2ia9hb2QzmNQ== Message-ID: <2EB36A07AAE8C44BBB1986425E7A22D0127E01BE33@atp-mbx1.in.nicta.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.4125-6.000.1038-17450.000 x-tm-as-result: No--42.080700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 221.199.216.123 X-SA-Exim-Mail-From: Paul.Steckler@nicta.com.au X-SA-Exim-Scanned: No (on ajax.nicta.com.au); SAEximRunCond expanded to false X-Spam: no; 0.00; steckler:01 steckler:01 buffer:01 recv:01 recv:01 ocaml:01 non-blocking:01 wrote:01 unix:01 unix:01 caml-list:01 data:02 data:02 buffers:04 blocking:04 I wrote: > Sometimes after receiving several requests, the Unix.send call that sends= a response > back to a Web client just blocks. The send buffer is pretty large (64k),= and the data > to be sent is always much less than that. I've found a solution. When receiving data from the browser, the socket on= ly ever made one call to Unix.recv, even if there was more data available, because = in this application, that was always enough. That strategy must have left some int= ernal buffers filled in the socket implementation. When I allow multiple calls t= o Unix.recv, until all data has been received, all calls to Unix.send proceed. Re the issue of multi-threadedness, I'm unable to build a multi-threaded OC= aml application using the Fedora distribution of the MingGW build, for reasons = I mentioned in an earlier message to this list. A non-blocking socket wouldn= 't have helped in this situation, anyway, because the blocking status of the s= ocket wasn't the issue. -- Paul -- Paul Steckler National ICT Australia paul DOT steckler AT nicta.com.au The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.