From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.wavenetuk.net (smtp.wavenetuk.net [195.26.36.10]) by sourceware.org (Postfix) with ESMTP id 49139385800B for ; Mon, 4 Jan 2021 02:35:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 49139385800B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp1.wavenetuk.net (Postfix) with ESMTPA id 34849120177D; Mon, 4 Jan 2021 02:35:19 +0000 (GMT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Update on shared memory coarrays From: Iain Sandoe In-Reply-To: <116ed7ff-7cdc-6324-c6c3-33fa9b1a036c@netcologne.de> Date: Mon, 4 Jan 2021 02:34:36 +0000 Cc: Fortran List , dhumieres.dominique@free.fr Content-Transfer-Encoding: 8bit Message-Id: <72972030-407F-4BD7-9B6C-D6937292E906@sandoe.co.uk> References: <522f101eda4e212f98f1f071165a46e5@free.fr> <79fdfc28ee95e21ba173dad5780b4e02@free.fr> <0770e8fb5b4b479afc98be8cf6221cc5@free.fr> <1a63faebd65be2a76627a7873d74c0c8@free.fr> <86fa53e3-155d-1912-8b88-b0789323ee09@netcologne.de> <2d94ef13-e12e-b941-dcb0-a9a79362f2d5@netcologne.de> <6D26C802-E6E0-473F-BB17-A9B373541980@sandoe.co.uk> <00ABD0DC-235B-4A4E-B9E0-B1200AC07EAD@sandoe.co.uk> <191C9834-F907-4CF0-B652-16E04A42B7AB@sandoe.co.uk> <5683F724-2723-4EE4-AC50-83FDB598D238@sandoe.co.uk> <2007278F-63EE-427A-BFB6-A504E96D3572@sandoe.co.uk> <116ed7ff-7cdc-6324-c6c3-33fa9b1a036c@netcologne.de> To: Thomas Koenig , =?utf-8?Q?Nicolas_K=C3=B6nig?= X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 02:35:22 -0000 Thomas Koenig via Fortran wrote: > Am 03.01.21 um 16:42 schrieb Iain Sandoe: >> [SHM] Shared Memory Objects >> The functionality described is optional. The functionality described is >> also an extension to the ISO C standard. >> … so support is optional and a failure in partial support is not an >> actual bug in compliance … > > It's a bug anyway :-) certainly, it’s inconvenient having different behaviout from other platforms. It seems shm is not a favoured IPC mechanism for Darwin (it’s possibly disallowed for GUI apps, according to search results - I didn’t check that) >> (we can file a radar, and maybe it gets fixed at some point - but that’s >> no help to all the existing system versions) > > Makes sense to file a bug report with Apple. And yes, we'll have to > deal with this some other way. [for command line apps] Either mechanism for accessing shm works; [1] shm_open / fd / mmap / munmap [2] shmget / shmat / shmdt <= allocation is rounded up to the nearest page boundary. Both have the constraint [on Darwin] that the size of the allocation cannot be increased after it is set (by ftruncate() [1] or shmget() [2]). It can be decreased (by [2] only), but it’s not clear if that actually has any physical effect. I guess that one ought to consider that a change in allocation could trigger a copy on any system (since there might not be contiguous memory pages available for an arbitrary increase) - so a strategy which either allocates separae fragments for each need - or waits until the size is known before allocation is likely to perform better on average, Iain