[boost] [interprocess] Platform-specific flags for mapped_region

108 views
Skip to first unread message

Andrey Semashev

unread,
Feb 12, 2013, 2:52:33 AM2/12/13
to bo...@lists.boost.org
Hi,

I wanted to try using Linux huge pages in my application, which uses
Boost.Interprocess currently for interprocess communication. However
there seems to be no way to pass MAP_HUGETLB flag to mmap in the
interface of mapped_region.

I understand that this is a platform-specific option, so probably it
would be best to just add an opaque unsigned int flags parameter to
the mapped_region constructor with the default value of 0. Or is there
a better way of doing this?

I'll create a ticket for this feature, but I wanted to know if the
general idea of this extension is welcome.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ion Gaztañaga

unread,
Feb 12, 2013, 3:52:00 AM2/12/13
to bo...@lists.boost.org
El 12/02/2013 8:52, Andrey Semashev escribió:
> Hi,
>
> I wanted to try using Linux huge pages in my application, which uses
> Boost.Interprocess currently for interprocess communication. However
> there seems to be no way to pass MAP_HUGETLB flag to mmap in the
> interface of mapped_region.
>
> I understand that this is a platform-specific option, so probably it
> would be best to just add an opaque unsigned int flags parameter to
> the mapped_region constructor with the default value of 0. Or is there
> a better way of doing this?

That's a good start. I guess we could define a platform-defined
map_flags_t type in Interprocess. For unix systems a "int", for windows
systems "unsigned long" (DWORD). That parameter could be passed as the
new last default parameter initialized to zero, say "extra_map_flags".
That flag will be OR-ed with internally produced flag before calling
mmap or MapViewOfFileEx. Would this be good enough?

> I'll create a ticket for this feature, but I wanted to know if the
> general idea of this extension is welcome.

Yes, please. Propagating this support to higher level abstractions, like
managed_shared_memory, is a bit more complicated, but let's not add it
if still there is no demand for that.

Best,

Ion

Andrey Semashev

unread,
Feb 12, 2013, 4:05:54 AM2/12/13
to bo...@lists.boost.org
On Tue, Feb 12, 2013 at 12:52 PM, Ion Gaztañaga <igazt...@gmail.com> wrote:
> El 12/02/2013 8:52, Andrey Semashev escribió:
>
>> Hi,
>>
>> I wanted to try using Linux huge pages in my application, which uses
>> Boost.Interprocess currently for interprocess communication. However
>> there seems to be no way to pass MAP_HUGETLB flag to mmap in the
>> interface of mapped_region.
>>
>> I understand that this is a platform-specific option, so probably it
>> would be best to just add an opaque unsigned int flags parameter to
>> the mapped_region constructor with the default value of 0. Or is there
>> a better way of doing this?
>
>
> That's a good start. I guess we could define a platform-defined map_flags_t
> type in Interprocess. For unix systems a "int", for windows systems
> "unsigned long" (DWORD). That parameter could be passed as the new last
> default parameter initialized to zero, say "extra_map_flags". That flag will
> be OR-ed with internally produced flag before calling mmap or
> MapViewOfFileEx. Would this be good enough?

Yes, that would be enough for my needs. Although from the
implementation perspective, I would probably make it MAP_NOSYNC by
default on *nix systems to remove the hardcoded OR in the constructor
body (POSIX version).

>> I'll create a ticket for this feature, but I wanted to know if the
>> general idea of this extension is welcome.
>
>
> Yes, please. Propagating this support to higher level abstractions, like
> managed_shared_memory, is a bit more complicated, but let's not add it if
> still there is no demand for that.

Agreed.

https://svn.boost.org/trac/boost/ticket/8030

Ion Gaztañaga

unread,
Feb 12, 2013, 4:58:00 AM2/12/13
to bo...@lists.boost.org
El 12/02/2013 10:05, Andrey Semashev escribió:

> Yes, that would be enough for my needs. Although from the
> implementation perspective, I would probably make it MAP_NOSYNC by
> default on *nix systems to remove the hardcoded OR in the constructor
> body (POSIX version).

Ok, good catch.

> https://svn.boost.org/trac/boost/ticket/8030

Thanks,

Ion
Reply all
Reply to author
Forward
0 new messages