From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p8DIj3DH006694 for ; Tue, 13 Sep 2011 20:45:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAESkb07U436rimdsb2JhbABChFOjGxQBAQEKCQ0HEgUjgVMBAQUjVhALGgImAgJXBhMJh3ACpVqKGYEshDGBEQSMH4w3jAs X-IronPort-AV: E=Sophos;i="4.68,375,1312149600"; d="scan'208";a="108904811" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Sep 2011 20:44:58 +0200 Received: from office1.lan.sumadev.de (dslb-094-219-218-023.pools.arcor-ip.net [94.219.218.23]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LcERJ-1RSOWy272T-00jQle; Tue, 13 Sep 2011 20:44:57 +0200 Received: from [192.168.1.111] (tmo-106-243.customers.d1-online.com [80.187.106.243]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id D0948C00C7; Tue, 13 Sep 2011 20:44:56 +0200 (CEST) From: Gerd Stolpmann To: Matej Kosik Cc: caml-list@yquem.inria.fr In-Reply-To: <4E6F400C.8020303@fiit.stuba.sk> References: <4E6F400C.8020303@fiit.stuba.sk> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Sep 2011 20:44:52 +0200 Message-ID: <1315939492.7337.4.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:vyWBmgDf9rb1ooYMhxiVrOvGimqmNAIhrXRrCp8yn18 AtsnDNbOxcj5mXGpKrHBHPlbppIFOu86ObKj7Pg9OxyY7xlbHX Y9faDtm2qGo5Qd+j8HU7x714iLdyLh7HY2Wg0jBAl2wiFcvXem 5lDUrAbLMAvwW3gqmPQMUht2Y7Yd2YBqyJGvSeKZE6+K/fUV7M 4Ye2XQdBOSaXM3feBn44qBU0RvYx0wzKcxyftQOlWU1MqwjodE sLfipPP6gsMimH9PxJ3JZqZfIgdyioALLyw2BrVdITsHPB27fV 21aAZyZxCDMMRsZwnrAyu2q98GZZaAzMeXPr6VR5Mq6VwLMPOE eCxq5qEf9CKCj3MbvX9hm9nEKSiRqJT0zi6aVn5NG Subject: Re: [Caml-list] interesting (unexpected) sideeffect Am Dienstag, den 13.09.2011, 13:35 +0200 schrieb Matej Kosik: > Hi, > > I have noticed that when I compile my program with > > ocamlc -vmthread ... threads.cma ... > > options, then > > Unix.set_nonblock > > function does not work. I.e. Unix.recv function called with a given > socket can block. Is this an intended behavior? Maybe not intended, but accepted (I reported that already years ago). The VM threads have serious limits, and are not meant as a replacement for kernel threads. So, some properties of file descriptors are always reset on occasion (VM context switch, or Unix.select). I guess it is too difficult to get this right. Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. ------------------------------------------------------------