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 4ABC23858006 for ; Sun, 3 Jan 2021 14:55:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4ABC23858006 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 8A2821201774; Sun, 3 Jan 2021 14:55:39 +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: <5683F724-2723-4EE4-AC50-83FDB598D238@sandoe.co.uk> Date: Sun, 3 Jan 2021 14:54:30 +0000 Cc: dhumieres.dominique@free.fr, Fortran List Content-Transfer-Encoding: 8bit Message-Id: <2007278F-63EE-427A-BFB6-A504E96D3572@sandoe.co.uk> References: <3d57a473-4025-890d-d365-6c2f82e7f513@netcologne.de> <0e1c519febec1c47c411339269455b9d@free.fr> <7e332e70-246e-b44e-7689-477642bf114c@netcologne.de> <23f5fbb548e75b1a5029162b31a8ddd7@free.fr> <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> To: =?utf-8?Q?Nicolas_K=C3=B6nig?= , Thomas Koenig 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: Sun, 03 Jan 2021 14:55:42 -0000 Iain Sandoe wrote: > Iain Sandoe wrote: > >> Iain Sandoe wrote: >> >>> Nicolas König wrote: >>> [IIUC what you mean by double-mapping] Allocating the same thing twice >>> seems likely to be an accident waiting to happen :) .. >> >> So the intent is: >> >> shm_allocate >> >> size the shm >> >> mmap the shm >> >> resize the shm >> will poke some more if I have a chance. > > There is an alternate shm interface on Darwin that allows manipulation of > the shm object more directly (and mapping/unmapping etc). > > It’s not clear if that mechanism will allow the shm object to be resized, > it doesn’t say in the man page that one cannot - but it doesn’t say one > can either. > > If I have a chance, I’ll try to recode the testcase to use that interface > and see if it works. Well .. (with this interface) I can create a half-page shm segment, and then expand that to a whole page .. but it doesn’t seem to allow > 1 page in the segment. That limitation is not spelled out in the man pages (might still be some mistake in my usage). AFAICT it rounds up to a page, which means that the second request can be honoured without a reallocation. It seems that the total shared memory supported by the (configured values) in the Darwin kernel might be quite small anyway : $ sysctl -a |grep shm kern.sysv.shmmax: 4194304 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 1024 However shm_open interface *does* appear to allow arbitrary sized segments [at least not reporting an error to the first call to ftruncate()] - but to deny a resize once created. seems more background reading will be needed … Iain