From stdcxx-dev-return-1760-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Mon Jul 17 16:23:20 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 63719 invoked from network); 17 Jul 2006 16:23:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Jul 2006 16:23:00 -0000 Received: (qmail 66509 invoked by uid 500); 17 Jul 2006 16:21:31 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 64416 invoked by uid 500); 17 Jul 2006 16:21:22 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 63870 invoked by uid 99); 17 Jul 2006 16:21:19 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 09:21:19 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [212.82.213.172] (HELO exkiv.kyiv.vdiweb.com) (212.82.213.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 08:54:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6A9B9.3B3F6F21" Subject: RE: svn commit: r421918 - in /incubator/stdcxx/trunk/tests: include/rw_alloc.h src/alloc.cpp Date: Mon, 17 Jul 2006 18:54:18 +0300 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: svn commit: r421918 - in /incubator/stdcxx/trunk/tests: include/rw_alloc.h src/alloc.cpp Thread-Index: AcanqkyKWUy/xx9/SCuWRwNyL1NijgCDr7LA From: "Farid Zaripov" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C6A9B9.3B3F6F21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Martin Sebor [mailto:sebor@roguewave.com]=20 > Sent: Saturday, July 15, 2006 4:02 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r421918 - in=20 > /incubator/stdcxx/trunk/tests: include/rw_alloc.h src/alloc.cpp >=20 [...] > Instead of _rw_binary_search/_rw_lower_bound, would it be=20 > possible to use the standard C function bsearch()? The bsearch() potentially can work slower than _rw_binary_search because of call of compare function which is not inlined. Anyway _rw_lower_bound is needed for finding the insertion place of the new item (_rw_table_insert). > The error handling in the file isn't very robust: we=20 > shouldn't just assert that the system calls succeeded; we=20 > should print out an error message and either exit with a=20 > non-zero exit status or return a value indicating a failure=20 > (if possible). If the former, the mechanism to use is=20 > rw_error() and/or rw_fatal(). The %m and %{#m} directives let=20 > you format the text of the error message corresponding to the=20 > value of errno and the name of the EXXX variable, respectively. Done. The diff file is attached. > Finally, I'm not sure I understand the purpose of the=20 > MemRWGuard class. The ctor sets one kind of permissions on a=20 > page of memory and the dtor sets another. Some functions do=20 > things in between the invocations of the two, others don't.=20 > It's not clear to me whether all invocations of the ctor and=20 > dtor really need the dtor to run or not. In other words, it's=20 > not clear to me that plain old functions wouldn't be more=20 > appropriate. Can you shed some light on this? The MemRWGuard is scope guard class. The dynamic memory, used for rw_alloc () is read-only the most of time (to prevent from the user modification). When rw_alloc () inserts the new item to the list of BlockInfo or to table of Pair it is needed to set the r/w access before the insertion and then restore access to the r/o. The MemRWGuard does this. The mprotect() requires address aligned to the memory page boundary and additional task of the MemRWGuard constructor is recalculation of the passed address and size considering the alignment. Farid. ------_=_NextPart_001_01C6A9B9.3B3F6F21--