From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 39DEB7F891 for ; Thu, 20 Mar 2014 08:42:52 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anders@fugmann.net) identity=pra; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anders@fugmann.net designates 90.184.182.235 as permitted sender) identity=mailfrom; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@fw.fugmann.net) identity=helo; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="postmaster@fw.fugmann.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAFKbKlNauLbr/2dsb2JhbABagmXAcoMPgTB0giUBAQEDAThAAQULCxgJFg8JAwIBAgFFBg0BBwKHbQkD0CUXjmUHhDgBA6p3gy4 X-IPAS-Result: AqIEAFKbKlNauLbr/2dsb2JhbABagmXAcoMPgTB0giUBAQEDAThAAQULCxgJFg8JAwIBAgFFBg0BBwKHbQkD0CUXjmUHhDgBA6p3gy4 X-IronPort-AV: E=Sophos;i="4.97,693,1389740400"; d="scan'208";a="53379497" Received: from 0405ds1-vaer.1.fullrate.dk (HELO fw.fugmann.net) ([90.184.182.235]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 20 Mar 2014 08:42:51 +0100 Received: from [IPv6:2a01:3a0:1:601:cabc:c8ff:fe9f:e077] (unknown [IPv6:2a01:3a0:1:601:cabc:c8ff:fe9f:e077]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fw.fugmann.net (Postfix) with ESMTPSA id 0237C7467C7; Thu, 20 Mar 2014 08:42:48 +0100 (CET) Message-ID: <532A9BF7.6050705@fugmann.net> Date: Thu, 20 Mar 2014 08:42:47 +0100 From: Anders Fugmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: ygrek CC: caml-list References: <532A0A5E.6070107@fugmann.net> <1395271296.27397.11.camel@zotac> <20140320132941.09aa04f4@kiwi.local.tld> In-Reply-To: <20140320132941.09aa04f4@kiwi.local.tld> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Validation-by: anders@fugmann.net Subject: Re: [Caml-list] Bug when printing from signal handlers? On 03/20/2014 06:29 AM, ygrek wrote: > > stdlib channels are protected with non-recursive mutex, so the deadlock on re-entrant invocation is guaranteed. I also assumed when I first saw the behavior that it was some deadlock. But it seems that that is not the case as the system enters a live lock and just sits there burning off cpu time. > AFAICS runtime system tries to execute signal immediately (see signal_handle in asmrun/signals_asm.c) > and if that is not possible - records signal for later execution. > Anyway doing complex stuff in signal handler is a bad idea, because even with delayed processing (when > things are safe from the libc point of view) the points of invocation of OCaml signal handler are scattered > all around the program (allocation sites) and any OCaml resource that doesn't support reentrant usage will break > the program. Maybe the documentation should be updated to explain how signal handling works and what is allowed in signal handers. Possibly also ideas on how to cope with these limitations. I circumvented the problem by using unbuffered writes (Unix.write), but it makes me wonder if I have code erroneous code lying around. /Anders