From user-return-31077-archive-asf-public=cust-asf.ponee.io@commons.apache.org Sun Jan 21 01:22:44 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 7AF5C18066D for ; Sun, 21 Jan 2018 01:22:44 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6ADE3160C3B; Sun, 21 Jan 2018 00:22:44 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B01E2160C38 for ; Sun, 21 Jan 2018 01:22:43 +0100 (CET) Received: (qmail 98253 invoked by uid 500); 21 Jan 2018 00:22:37 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 98242 invoked by uid 99); 21 Jan 2018 00:22:37 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jan 2018 00:22:37 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id DDA6C1A0903 for ; Sun, 21 Jan 2018 00:22:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.283 X-Spam-Level: *** X-Spam-Status: No, score=3.283 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=1.974, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 3h6oIfeYJAba for ; Sun, 21 Jan 2018 00:22:35 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id C52CE5F23E for ; Sun, 21 Jan 2018 00:22:34 +0000 (UTC) X-Originating-IP: 209.85.213.181 Received: from mail-yb0-f181.google.com (mail-yb0-f181.google.com [209.85.213.181]) (Authenticated sender: gmail@vafer.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4E34441C07E for ; Sun, 21 Jan 2018 01:22:32 +0100 (CET) Received: by mail-yb0-f181.google.com with SMTP id 65so1987894ybz.6 for ; Sat, 20 Jan 2018 16:22:32 -0800 (PST) X-Gm-Message-State: AKwxytcNJFusz92n/7dhOPqPcNeQF/jMSd/yUMz15xkfJW2Nqq6c9iE6 iC1k0OHmgzWTcTSACPzJiwRvnfNjKTPQ/RvnwUo= X-Google-Smtp-Source: AH8x227ADfXngMoSJzdEhPO2BWGTz2g8xpNslsTeEKtr74vPQHuQKmvTYDL/tLoTelsi2EAh4ygs2h/KV6o0fRxFArk= X-Received: by 10.37.46.2 with SMTP id u2mr3042218ybu.52.1516494151749; Sat, 20 Jan 2018 16:22:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.139.143 with HTTP; Sat, 20 Jan 2018 16:21:51 -0800 (PST) In-Reply-To: References: From: Torsten Curdt Date: Sun, 21 Jan 2018 01:21:51 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [javaflow] - how to use continuation in JNI boundary To: Commons Users List Content-Type: multipart/alternative; boundary="089e0828e3e838199005633e4f9e" --089e0828e3e838199005633e4f9e Content-Type: text/plain; charset="UTF-8" This does not remove the restriction on the synchronization - that still exists. The thread could do something else during the wait - but that's another story. There just is not automatic suspend on wait. And it begs the question how such a thing would/should look like. I am not saying this isn't something that could be interesting to investigate - but this is just not what javaflow is. The current javaflow implementation is about state storing and restoring - not scheduling and pooling. While you could improve thread usage by implementing thread re-use during wait, the big problem will still always be the synchronized code. So it really feels like you are trying to solve a problem from the wrong end. Anyway - my 2 cents. Take them or leave 'em ;) On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto < cristian.lorenzetto@gmail.com> wrote: > It is absolutely not true. If a coroutine execute > > synchonized(lock){ lock.wait() } > > the lock.wait blocks the thread. Why i have to block the thread if thread > can running other corotuines in the while? > lock.wait must supend the coroutine and resuming another coroutine > > 2018-01-21 0:23 GMT+01:00 Torsten Curdt : > > > I am sorry but I must be missing something here. > > > > The code uses synchronization blocks and mutexes to explicitly make sure > > threads don't interfere which each other. > > This restriction will be there because of resource sharing and the java > > memory model. > > Instrumenting wait/notify cannot magically remove that restriction. > > > > Based on queuing theory you can move your bottleneck to your mutexes - > but > > that's about it. > > > --089e0828e3e838199005633e4f9e--