From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id 03CB639484BF for ; Thu, 13 Jan 2022 10:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03CB639484BF Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (ae233132.dynamic.ppp.asahi-net.or.jp [14.3.233.132]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 20DAujsC026798 for ; Thu, 13 Jan 2022 19:56:46 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 20DAujsC026798 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1642071406; bh=cOqzQj7XOAJSGRUWD1yjoKJPzLQ+oS+xlOBl41dpPTw=; h=Date:From:To:Subject:In-Reply-To:References:From; b=meWzU6RedkXc0qKamEIz0WP8XRzu1e7VLbd5Bj3B6QhGJbSCfsiWWiqsKsBBa4jq5 AFwApSraDrrXlWxNvTsdUicv7VUNN1PhFRH2YNsdHKbqxmgTIf+yqFgiX+ucmJt26x Okm+OFhG4JEI0aHbpZgLqGdbvITkjkmVDV/kIVNPG+Xb8ZWHev2RQn6sjhGV/R3s/m q0YteLupdol/Wn9a7yQOFnfTVtwT3QgH7j4gxjmGwMLokrocHReK9rGPAF/w6IVpDW VxNQZPwpXx85JK6l6QFS9acqyp8foOjmBbmk4TiLwb4k0u8XiU2vd7TRBXmGSPIMHn 4mBhRXloWg7fg== X-Nifty-SrcIP: [14.3.233.132] Date: Thu, 13 Jan 2022 19:56:46 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: deadlock on console mutex in gdb Message-Id: <20220113195646.7cac402c3e8e9077ab7789d2@nifty.ne.jp> In-Reply-To: <87mtkribfg.fsf@gmail.com> References: <20211223054409.610242feb0e96199904b3c9e@nifty.ne.jp> <20211223182440.e37115a4493516aca7ed7873@nifty.ne.jp> <87mtkribfg.fsf@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 10:57:03 -0000 Sorry for being absent for a long time. On Thu, 23 Dec 2021 11:32:51 -0400 David McFarland wrote: > Takashi Yano writes: > > > I think there is no other way than not to wait mutex in the > > debugger process. If anyone have any other idea, please let > > me know. > > I have a few thoughts: > > I believe gdb currently just uses windows debugging APIs, so it doesn't > treat cygwin as an operating system. On other operating systems there > would be some mechanism to prevent kernel mutexes from deadlocking. It > obviously can't just wait for all syscalls to complete, but it must > avoid blocking kernel tasks that hold mutexes. Perhaps we could do > something similar on cygwin, but it would probably mean providing > cygwin-specific debugging APIs and support in gdb. I'd have to do some > more research into how this works on e.g. Linux. > > Can we avoid using inter-process mutexes for this? What would you expect > to break if we just used a per-process mutex? I think we need inter-process mutex. Otherwise, write() calls from multiple process will not be done in atomic. > If we do need an inter-process mutex, perhaps we could have a daemon > process responsible for it? I think that would be a bit of a departure > for cygwin. I cannot imagine how to implement this... -- Takashi Yano