Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 13D7C10604 for ; Tue, 15 Oct 2013 10:48:17 +0000 (UTC) Received: (qmail 49651 invoked by uid 500); 15 Oct 2013 10:48:12 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 49505 invoked by uid 500); 15 Oct 2013 10:48:06 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 49485 invoked by uid 99); 15 Oct 2013 10:48:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Oct 2013 10:48:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.215.43 as permitted sender) Received: from [209.85.215.43] (HELO mail-la0-f43.google.com) (209.85.215.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Oct 2013 10:47:56 +0000 Received: by mail-la0-f43.google.com with SMTP id ec20so505326lab.16 for ; Tue, 15 Oct 2013 03:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CJTpscSM7nPTpTNaH2apc5nbFyEJXmlypS4s7pGlLUw=; b=WgcN6/iDJbp9VGS2OuzRRmp/0mMJ5vMybBnWQy/FnxJhH66qYF3rkfoqIRqrZMYAOP SvvieJPmxJOA8ZLpeLzFK/1Gk4c5OfZvQW6XX7bJFJnwdcF0ghwU+TD5ch7enicBvpcp HYxghIO/OsNzeEJUwWv3jeiXBSUb67FNwOiebtFh2U36Y4twhLaasI3ZMrihh/wCp5NV oJkH2Yd+KvQNFFPYdmmLpdsUm+Q3mG6INa7zNaJARzjsjRfH3seWPOhWmhgy6IYS2ED1 ocXrSe0epDenrzs9Y5fOj4dl+7RrpmRNjDqNxSiaQ7czYkXxZYG6GZ4S/B6aojluLinF suLg== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr34979563lbh.9.1381834056074; Tue, 15 Oct 2013 03:47:36 -0700 (PDT) Received: by 10.114.187.71 with HTTP; Tue, 15 Oct 2013 03:47:35 -0700 (PDT) In-Reply-To: <525CCC1A.8060702@apache.org> References: <525CCC1A.8060702@apache.org> Date: Tue, 15 Oct 2013 06:47:35 -0400 Message-ID: Subject: Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows From: Jeff Trawick To: Mladen Turk Cc: APR Developer List Content-Type: multipart/alternative; boundary=001a1133aa860d0ade04e8c5509c X-Virus-Checked: Checked by ClamAV on apache.org --001a1133aa860d0ade04e8c5509c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk wrote: > On 10/15/2013 02:27 AM, Jeff Trawick wrote: > > >> Or in a more APR-like fashion, add apr_shm_create_ex() and >> apr_shm_attach_ex() which have a special processing flag (bitmap). For >> Windows, APR_SHM_NS_LOCAL and APR_SHM_NS_GLOBAL would be respected. That >> could be used by an app that can't with with APR's >> imperfect attempts to manage global vs. local. I don't think there is a >> perfect anyway. >> >> As 1.5.x hasn't been released yet, the _ex() functions could be in it. >> >> >> > Replacing Global with Local would basically limit the apr_shm API and it > won't > allow IPC using shm across sessions. With services running in Session0 shm > is one > of the effective IPC mechanisms. Using _ex() api and making _create() and > _attach() > as macros should do the trick. Although not sure what should be default > (global or local) > I'd go for backward compatibility (no sudden surprises when changing > version) > Yeah (backward compatibility); specifying APR_SHM_NS_LOCAL or _GLOBAL would bypass the current logic in trunk. I still like the heuristic that allows non-privileged processes to collaborate via shared memory without adding any platform-specific flags. The flag would be needed if an app wants to use Local even if the process might be privileged, or an app must use Global to operate (and fail if it is not privileged). > > > Regards > -- > ^TM > -- Born in Roswell... married an alien... http://emptyhammock.com/ --001a1133aa860d0ade04e8c5509c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk <mturk@apache= .org> wrote:
On 10/15/2013 02:27 AM, Je= ff Trawick wrote:


Or in a more APR-like fashion, add apr_shm_create_ex() and apr_shm_attach_e= x() which have a special processing flag (bitmap). =A0For Windows, =A0APR_S= HM_NS_LOCAL and APR_SHM_NS_GLOBAL would be respected. =A0That could be used= by an app that can't with with APR's
imperfect attempts to manage global vs. local. =A0I don't think there i= s a perfect anyway.

As 1.5.x hasn't been released yet, the _ex() functions could be in it.<= br>


Replacing Global with Local would basically limit the apr_shm API and it wo= n't
allow IPC using shm across sessions. With services running in Session0 shm = is one
of the effective IPC mechanisms. Using _ex() api and making _create() and _= attach()
as macros should do the trick. Although not sure what should be default (gl= obal or local)
I'd go for backward compatibility (no sudden surprises when changing ve= rsion)

Yeah (backward compatibility); s= pecifying APR_SHM_NS_LOCAL or _GLOBAL would bypass the current logic in tru= nk. =A0I still like the heuristic that allows non-privileged processes to c= ollaborate via shared memory without adding any platform-specific flags. = =A0The flag would be needed if an app wants to use Local even if the proces= s might be privileged, or an app must use Global to operate (and fail if it= is not privileged).

=A0


Regards
--
^TM



-- Born in Roswell... married an alien...
http://emptyhammock.com/
--001a1133aa860d0ade04e8c5509c--