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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 1D00BBB81 for ; Mon, 20 Mar 2006 11:40:11 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k2KAeArk021195 for ; Mon, 20 Mar 2006 11:40:10 +0100 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 LAA04052 for ; Mon, 20 Mar 2006 11:40:10 +0100 (MET) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k2KAe9UN021192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Mar 2006 11:40:09 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from first.in-berlin.de (e178025060.adsl.alicedsl.de [85.178.25.60]) (authenticated bits=0) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id k2KAe5qP007598 for ; Mon, 20 Mar 2006 11:40:07 +0100 Received: by first.in-berlin.de (Postfix, from userid 501) id C60E4233DCC; Mon, 20 Mar 2006 11:39:19 +0100 (CET) Date: Mon, 20 Mar 2006 11:39:19 +0100 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Severe loss of performance due to new signal handling Message-ID: <20060320103919.GA1167@first.in-berlin.de> References: <441E760D.6010801@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <441E760D.6010801@inria.fr> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at nez-perce with ID 441E868A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 441E8689.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 3.08.4:01 threads:01 ocaml:01 threads:01 stdout:01 stdout:01 cvs:01 proble:01 unix:01 c-api:01 handler:01 handler:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Mon, Mar 20, 2006 at 10:29:49AM +0100, Xavier Leroy wrote: > > It seems that changes to signal handling between OCaml 3.08.4 and 3.09.1 > > can lead to a very significant loss of performance (up to several orders > > of magnitude!) in code that uses threads and performs I/O (tested on > Linux). > > [...] > > Maybe some assembler guru can repeat this result and explain to us > > what's going on... > > Short explanation: atomic instructions are dog slow. > > Longer explanation: > > OCaml 3.09 fixed a number of long-standing bugs in signal handling > that could cause signals to be "lost" (not acted upon). The fixes, [...] > Now, you may wonder why the problem appears mainly with threaded > programs. The reason is that programs linked with the Thread library, > even if they do not create threads, check for signals much more > often, because they enter and leave blocking sections more often. In > your example, each call to "print_char" needs to lock and unlock the > stdout channel, causing two signal polls each time. Is this really necessary? Doing a write to stdout with locking... if not explicitly wanted?! > So, it's time to go back to the drawing board. Fortunately, it > appears that reliable polling of signals is possible without atomic > processor instructions. Expect a fix in 3.09.2 at the latest, and > probably within a couple of weeks in the CVS. I'm not clear about what your proble is with lost signals, but when using signals on Unix/Linux-systems, you can use UNIX-API, with sigaction/sigprocmask etc. you can do things well, and with the signal-function which C provides things are bad/worse. The C-API signal-function signal(3) clears out the signal handler after a call to it. In the sigaction/sigprocmask/... functions the handler remains installed. But if this is what you think about (and how it will be done on windows or other systems) I don't know, but maybe this is a hint that matters. BTW: I saw that in the Unix-module the unix-signalling functions are now included... (the ywere not on older versions of Ocaml). Ciao, Oliver