From user-return-31080-archive-asf-public=cust-asf.ponee.io@commons.apache.org Tue Jan 23 13:45:51 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 23A32180621 for ; Tue, 23 Jan 2018 13:45:51 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 13605160C4D; Tue, 23 Jan 2018 12:45:51 +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 5B2DE160C17 for ; Tue, 23 Jan 2018 13:45:50 +0100 (CET) Received: (qmail 89940 invoked by uid 500); 23 Jan 2018 12:45:49 -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 89903 invoked by uid 99); 23 Jan 2018 12:45:48 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2018 12:45:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E155AC320F for ; Tue, 23 Jan 2018 12:45:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id aYdKib6oFd4S for ; Tue, 23 Jan 2018 12:45:45 +0000 (UTC) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 4451E5F2AB for ; Tue, 23 Jan 2018 12:45:45 +0000 (UTC) X-Originating-IP: 209.85.161.181 Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) (Authenticated sender: gmail@vafer.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id B647BFB8A4 for ; Tue, 23 Jan 2018 13:45:44 +0100 (CET) Received: by mail-yw0-f181.google.com with SMTP id x190so114351ywd.10 for ; Tue, 23 Jan 2018 04:45:44 -0800 (PST) X-Gm-Message-State: AKwxytde/JFprdDt7XcaA0WBWKHm/S1xaxhChW3HT+5vjgE94T+FdPEh d0oHacTvsmOBDfl8I94O2vaDXFEK3wyToEohFRc= X-Google-Smtp-Source: AH8x225c/8Y7jy2KLzUPK8cjFVdJWc8lwowVnAEb4tgVTHXJRM0DYcmLkExuPBjRqx+gn5/SKFgpT0+e0ih8VZLuLhc= X-Received: by 10.129.145.15 with SMTP id i15mr2268766ywg.178.1516711543555; Tue, 23 Jan 2018 04:45:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.139.143 with HTTP; Tue, 23 Jan 2018 04:45:03 -0800 (PST) In-Reply-To: References: From: Torsten Curdt Date: Tue, 23 Jan 2018 13:45:03 +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="94eb2c093e3cc7ce81056370ec0a" --94eb2c093e3cc7ce81056370ec0a Content-Type: text/plain; charset="UTF-8" I don't want to discourage you from contributing but... as also descripted in the Loom proposal already suggests - it's much more than just patching the Instrumenter. If you want to re-use the threads you also need to add some kind of pooling and scheduling mechanism. On Sun, Jan 21, 2018 at 2:00 AM, Cristian Lorenzetto < cristian.lorenzetto@gmail.com> wrote: > I read now Loom project is thinking to do exactly what i proposed. But when > it will be available? uhmmm i think i could require years... > I dont know , maybe i could patch the instrumenter > > 2018-01-21 1:21 GMT+01:00 Torsten Curdt : > > > 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. > > > > > > > > > > --94eb2c093e3cc7ce81056370ec0a--