From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id C36811F97E for ; Wed, 28 Nov 2018 03:30:55 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2DCF6120CD3; Wed, 28 Nov 2018 12:30:53 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5690A120C67 for ; Wed, 28 Nov 2018 12:30:50 +0900 (JST) Received: by filter0171p3mdw1.sendgrid.net with SMTP id filter0171p3mdw1-30246-5BFE0BE7-19 2018-11-28 03:30:47.396119937 +0000 UTC m=+51291.487154332 Received: from herokuapp.com (ec2-54-163-134-28.compute-1.amazonaws.com [54.163.134.28]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id ojaKYQNMSGOcDT6l4rvn6w for ; Wed, 28 Nov 2018 03:30:47.286 +0000 (UTC) Date: Wed, 28 Nov 2018 03:30:47 +0000 (UTC) From: merch-redmine@jeremyevans.net To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65504 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15350 X-Redmine-Issue-Author: normalperson X-Redmine-Sender: jeremyevans0 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5wAsHmtqo+Y2UH6XqBFdouvhTvcAinxnJbSZ 4kmA1rsSB5B5X4wcRbm0U0aZ7gddh7H3EPI/t41T2webKtnpYrxbTiC/wAH0U1/0MUeJ0ZaK7JSNEf 2umhaoHkxnxoweXJ6iDxQGH8e05m1pkBCR92jJXUycBlsVUZrZ3/+VV+jg== X-ML-Name: ruby-core X-Mail-Count: 90108 Subject: [ruby-core:90108] [Ruby trunk Feature#15350] [PATCH] thread_sync.c (queue_sleep): remove deadlock checking X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15350 has been updated by jeremyevans0 (Jeremy Evans). normalperson (Eric Wong) wrote: > merch-redmine@jeremyevans.net wrote: > > I expect this would make it more difficult to debug > > multithreaded use of Queue, since ruby would hang instead of > > raising a fatal exception as it does currently (assuming I > > understand the patch correctly). As multithreaded use of > > Queue is probably more common than signal handler use of > > Queue, I'm not sure changing the default behavior is a good > > idea. > > I've never seen Queue usage as difficult to get right. I see > some (not much) usefulness of deadlock checking for mutex and > CV; but Queue is like a pipe and there's already plenty of > opportunities for pipe-using code to deadlock. I use Queue pretty extensively when testing to ensure deterministic behavior in multithreaded code, and I can say it would be a lot more difficult to write such tests if a mistake caused the tests to deadlock instead of raising a fatal exception. > But I'm not sure if increasing API footprint for Queue is a good > idea, either. That's a fair point. However, considering you can work around the current deadlock detection with `Thread.new{loop{sleep(1000000)}}` before calling `Queue#pop`, the deadlock detection doesn't really cause major problems if you want to use Queue in signal handlers. Example: ~~~ ruby q = Queue.new Signal.trap(:INT){q.push nil} Thread.new{loop{sleep(1000000)}} q.pop ~~~ ---------------------------------------- Feature #15350: [PATCH] thread_sync.c (queue_sleep): remove deadlock checking https://bugs.ruby-lang.org/issues/15350#change-75229 * Author: normalperson (Eric Wong) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- thread_sync.c (queue_sleep): remove deadlock checking Queue may be used inside signal handlers nowadays, so deadlock checking is unnecessary and prevents single-threaded use. We don't have deadlock checking for reading pipes/socket or File#flock, either. This IS a behavior change; but I don't think there is a risk of incompatibility (aside from future code not working on old Rubies) ---Files-------------------------------- 0001-thread_sync.c-queue_sleep-remove-deadlock-checking.patch (2.44 KB) -- https://bugs.ruby-lang.org/