You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/07/26 11:28:35 UTC
Proposal to extend portlib with enhanced mmap functions:
Hi, all
I raise HARMONY-982 (https://issues.apache.org/jira/browse/HARMONY-982)
about the portlib extension on mmap. And here goes my proposal about the
extension, comments are welcome.
Currently portlib has some mmap support, but the support is limited in
several ways:
1. it only mmap in private(copy_on_write) mode
2. it always mmap whole file
3. it only accepts filename, but nio needs to map a already opened file
descriptor
so that the Harmony's mmap is implemented in platform dependent codes so
far, I think these are good candidates as the portlib extension.
To support the nio's requirement, three current mmap functions need to
be enhanced - hymmap_map_file, hymmap_unmap_file and
hymmap_capabilities, one new method is added: hymmap_msync. Please see
details below:
1. hymmap_map_file
/**
* Map a part of file into memory.
*
* @param [in] portLibrary The port library
* @param [in] file The file descriptor/handle of the
already open file to be mapped
* @param [in] offset The file offset of the part to be
mapped
* @param [in] size The number of bytes to be mapped,
if zero, the whole file is mapped
* @param [in] mappingName The name of the file mapping
object to be created/opened.
* If a named
object is not required, this parameter can be specified as NULL
* @param [in] flags Flags relating to the mapping:
* @args
HYPORT_MMAP_FLAG_READ read only map
* @args
HYPORT_MMAP_FLAG_WRITE read/write map
* @args
HYPORT_MMAP_FLAG_COPYONWRITE copy on write map
* @args
HYPORT_MMAP_FLAG_SHARED share memory mapping with other
processes
* @args
HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not
share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE)
*
* @return A pointer to the start of the
mapped file or NULL is an error has occurred
*/
void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64
offset, UDATA size, const char *mappingName, U_32 flags)
This will use CreateFileMapping() and MapViewOfFile() on Windows and
mmap() on Unix to map the file into the process' address space. In both
cases, it will return the address to which the file has been mapped.
The memory mapping API's on all platforms require an open handle/file
descriptor to the file to be mapped.
The mapAddress parameter has been removed from the original signature.
This was an output parameter from the API containing the address at
which the file has been mapped. However, this is the return value of
the function and was therefore duplication.
2. hymmap_msync
/**
* Synchronise updates to memory mapped file region with file on disk.
The call may wait for the file write
* to complete or this may be scheduled for a later time and the
function return immediately, depending on
* the flags setting
*
* @param [in] portLibrary The port library
* @param [in] start Pointer to the start of the
memory mapped area to be synchronised
* @param [in] length Length of the memory mapped area
to be synchronised
* @param [in] flags Flags controlling the behaviour
of the function:
* @args
HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not
*
return until file updated. Note that to achieve this on Windows
requires the
*
file to be opened with the FILE_FLAG_WRITE_THROUGH flag
* @args
HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns
*
immediately, file will be updated later
* @args
HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same
*
file be invalidated, so that they can be updated with the values just
written
*
* @return 0 on success, -1 on failure.
Errors will be reported using the usual port library mechanism
*/
IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA length,
U_32 flags)
This function will use msync on Unix and FlushViewOfFile on Windows.
3. hymmap_unmap_file
/**
* Unmap previously mapped memory
*
* @param [in] portLibrary The port library
* @param [in] start Pointer to the start of the
memory mapped area
* @param [in] size The length of the mapped area
*/
void hymmap_unmap_file(HYPortLibrary portLibrary, void *start, UDATA size)
This existing API will be changed to take the start address returned
from hymmap_map_file and the size of the mapped area instead of the
current handle. The handle is not very clear as it is the start address
of the mapped area (equivalent to start) on Windows and a pointer to a
structure containing this and the size on Unix platforms. Explicitly
passing the start address and length will provide a clearer interface.
4. hymmap_capabilities
/**
* Check the capabilities available for HYMMAP at runtime for the
current platform
*
* @param [in] portLibrary The port library
*
* @return The capabilities available on this
platform
* @args
HYPORT_MMAP_CAPABILITY_READ
* @args
HYPORT_MMAP_CAPABILITY_WRITE
* @args
HYPORT_MMAP_CAPABILITY_COPYONWRITE
*/
I_32 hymmap_capabilities(HYPortLibrary portLibrary)
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [Portlib]Proposal to extend portlib with enhanced mmap functions:
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Sorry I didn't reply sooner. Have fun :)
geir
Paulex Yang wrote:
> Thank you for all your attention on this:), because seems no one
> objects, I'm going to assign HARMONY-982 to myself, and start to extend
> the portlib.
>
> Paulex Yang wrote:
>> Sorry I forgot to add the prefix just now.
>>
>> Paulex Yang wrote:
>>> Hi, all
>>>
>>> I raise HARMONY-982
>>> (https://issues.apache.org/jira/browse/HARMONY-982) about the portlib
>>> extension on mmap. And here goes my proposal about the extension,
>>> comments are welcome.
>>>
>>> Currently portlib has some mmap support, but the support is limited
>>> in several ways:
>>> 1. it only mmap in private(copy_on_write) mode
>>> 2. it always mmap whole file
>>> 3. it only accepts filename, but nio needs to map a already opened
>>> file descriptor
>>>
>>> so that the Harmony's mmap is implemented in platform dependent codes
>>> so far, I think these are good candidates as the portlib extension.
>>>
>>> To support the nio's requirement, three current mmap functions need
>>> to be enhanced - hymmap_map_file, hymmap_unmap_file and
>>> hymmap_capabilities, one new method is added: hymmap_msync. Please
>>> see details below:
>>>
>>> 1. hymmap_map_file
>>>
>>> /**
>>> * Map a part of file into memory.
>>> *
>>> * @param [in] portLibrary The port library
>>> * @param [in] file The file descriptor/handle of
>>> the already open file to be mapped
>>> * @param [in] offset The file offset of the part to
>>> be mapped
>>> * @param [in] size The number of bytes to be
>>> mapped, if zero, the whole file is mapped
>>> * @param [in] mappingName The name of the file mapping
>>> object to be created/opened.
>>> * If a named
>>> object is not required, this parameter can be specified as NULL
>>> * @param [in] flags Flags relating to the mapping:
>>> * @args
>>> HYPORT_MMAP_FLAG_READ read only map
>>> * @args
>>> HYPORT_MMAP_FLAG_WRITE read/write map
>>> * @args
>>> HYPORT_MMAP_FLAG_COPYONWRITE copy on write map
>>> * @args
>>> HYPORT_MMAP_FLAG_SHARED share memory mapping with other
>>> processes
>>> * @args
>>> HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not
>>> share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE)
>>> *
>>> * @return A pointer to the start of the
>>> mapped file or NULL is an error has occurred
>>> */
>>> void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64
>>> offset, UDATA size, const char *mappingName, U_32 flags)
>>>
>>> This will use CreateFileMapping() and MapViewOfFile() on Windows and
>>> mmap() on Unix to map the file into the process' address space. In
>>> both cases, it will return the address to which the file has been
>>> mapped.
>>>
>>> The memory mapping API's on all platforms require an open handle/file
>>> descriptor to the file to be mapped.
>>>
>>> The mapAddress parameter has been removed from the original
>>> signature. This was an output parameter from the API containing the
>>> address at which the file has been mapped. However, this is the
>>> return value of the function and was therefore duplication.
>>>
>>> 2. hymmap_msync
>>>
>>> /**
>>> * Synchronise updates to memory mapped file region with file on
>>> disk. The call may wait for the file write
>>> * to complete or this may be scheduled for a later time and the
>>> function return immediately, depending on
>>> * the flags setting
>>> *
>>> * @param [in] portLibrary The port library
>>> * @param [in] start Pointer to the start of the
>>> memory mapped area to be synchronised
>>> * @param [in] length Length of the memory mapped
>>> area to be synchronised
>>> * @param [in] flags Flags controlling the
>>> behaviour of the function:
>>> * @args
>>> HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not
>>> *
>>> return until file updated. Note that to achieve this on Windows
>>> requires the
>>> *
>>> file to be opened with the FILE_FLAG_WRITE_THROUGH flag
>>> * @args
>>> HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns
>>> *
>>> immediately, file will be updated later
>>> * @args
>>> HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same
>>> *
>>> file be invalidated, so that they can be updated with the values just
>>> written
>>> *
>>> * @return 0 on success, -1 on failure.
>>> Errors will be reported using the usual port library mechanism
>>> */
>>> IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA
>>> length, U_32 flags)
>>>
>>> This function will use msync on Unix and FlushViewOfFile on Windows.
>>>
>>> 3. hymmap_unmap_file
>>>
>>> /**
>>> * Unmap previously mapped memory
>>> *
>>> * @param [in] portLibrary The port library
>>> * @param [in] start Pointer to the start of the
>>> memory mapped area
>>> * @param [in] size The length of the mapped area
>>> */
>>> void hymmap_unmap_file(HYPortLibrary portLibrary, void *start, UDATA
>>> size)
>>>
>>> This existing API will be changed to take the start address returned
>>> from hymmap_map_file and the size of the mapped area instead of the
>>> current handle. The handle is not very clear as it is the start
>>> address of the mapped area (equivalent to start) on Windows and a
>>> pointer to a structure containing this and the size on Unix
>>> platforms. Explicitly passing the start address and length will
>>> provide a clearer interface.
>>>
>>> 4. hymmap_capabilities
>>>
>>> /**
>>> * Check the capabilities available for HYMMAP at runtime for the
>>> current platform
>>> *
>>> * @param [in] portLibrary The port library
>>> *
>>> * @return The capabilities available on this
>>> platform
>>> * @args
>>> HYPORT_MMAP_CAPABILITY_READ
>>> * @args
>>> HYPORT_MMAP_CAPABILITY_WRITE
>>> * @args
>>> HYPORT_MMAP_CAPABILITY_COPYONWRITE
>>> */
>>> I_32 hymmap_capabilities(HYPortLibrary portLibrary)
>>>
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [Portlib]Proposal to extend portlib with enhanced mmap functions:
Posted by Paulex Yang <pa...@gmail.com>.
Thank you for all your attention on this:), because seems no one
objects, I'm going to assign HARMONY-982 to myself, and start to extend
the portlib.
Paulex Yang wrote:
> Sorry I forgot to add the prefix just now.
>
> Paulex Yang wrote:
>> Hi, all
>>
>> I raise HARMONY-982
>> (https://issues.apache.org/jira/browse/HARMONY-982) about the portlib
>> extension on mmap. And here goes my proposal about the extension,
>> comments are welcome.
>>
>> Currently portlib has some mmap support, but the support is limited
>> in several ways:
>> 1. it only mmap in private(copy_on_write) mode
>> 2. it always mmap whole file
>> 3. it only accepts filename, but nio needs to map a already opened
>> file descriptor
>>
>> so that the Harmony's mmap is implemented in platform dependent codes
>> so far, I think these are good candidates as the portlib extension.
>>
>> To support the nio's requirement, three current mmap functions need
>> to be enhanced - hymmap_map_file, hymmap_unmap_file and
>> hymmap_capabilities, one new method is added: hymmap_msync. Please
>> see details below:
>>
>> 1. hymmap_map_file
>>
>> /**
>> * Map a part of file into memory.
>> *
>> * @param [in] portLibrary The port library
>> * @param [in] file The file descriptor/handle of
>> the already open file to be mapped
>> * @param [in] offset The file offset of the part to
>> be mapped
>> * @param [in] size The number of bytes to be
>> mapped, if zero, the whole file is mapped
>> * @param [in] mappingName The name of the file mapping
>> object to be created/opened.
>> * If a named
>> object is not required, this parameter can be specified as NULL
>> * @param [in] flags Flags relating to the mapping:
>> * @args
>> HYPORT_MMAP_FLAG_READ read only map
>> * @args
>> HYPORT_MMAP_FLAG_WRITE read/write map
>> * @args
>> HYPORT_MMAP_FLAG_COPYONWRITE copy on write map
>> * @args
>> HYPORT_MMAP_FLAG_SHARED share memory mapping with other
>> processes
>> * @args
>> HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not
>> share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE)
>> *
>> * @return A pointer to the start of the
>> mapped file or NULL is an error has occurred
>> */
>> void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64
>> offset, UDATA size, const char *mappingName, U_32 flags)
>>
>> This will use CreateFileMapping() and MapViewOfFile() on Windows and
>> mmap() on Unix to map the file into the process' address space. In
>> both cases, it will return the address to which the file has been
>> mapped.
>>
>> The memory mapping API's on all platforms require an open handle/file
>> descriptor to the file to be mapped.
>>
>> The mapAddress parameter has been removed from the original
>> signature. This was an output parameter from the API containing the
>> address at which the file has been mapped. However, this is the
>> return value of the function and was therefore duplication.
>>
>> 2. hymmap_msync
>>
>> /**
>> * Synchronise updates to memory mapped file region with file on
>> disk. The call may wait for the file write
>> * to complete or this may be scheduled for a later time and the
>> function return immediately, depending on
>> * the flags setting
>> *
>> * @param [in] portLibrary The port library
>> * @param [in] start Pointer to the start of the
>> memory mapped area to be synchronised
>> * @param [in] length Length of the memory mapped
>> area to be synchronised
>> * @param [in] flags Flags controlling the
>> behaviour of the function:
>> * @args
>> HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not
>> *
>> return until file updated. Note that to achieve this on Windows
>> requires the
>> *
>> file to be opened with the FILE_FLAG_WRITE_THROUGH flag
>> * @args
>> HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns
>> *
>> immediately, file will be updated later
>> * @args
>> HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same
>> *
>> file be invalidated, so that they can be updated with the values just
>> written
>> *
>> * @return 0 on success, -1 on failure.
>> Errors will be reported using the usual port library mechanism
>> */
>> IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA
>> length, U_32 flags)
>>
>> This function will use msync on Unix and FlushViewOfFile on Windows.
>>
>> 3. hymmap_unmap_file
>>
>> /**
>> * Unmap previously mapped memory
>> *
>> * @param [in] portLibrary The port library
>> * @param [in] start Pointer to the start of the
>> memory mapped area
>> * @param [in] size The length of the mapped area
>> */
>> void hymmap_unmap_file(HYPortLibrary portLibrary, void *start, UDATA
>> size)
>>
>> This existing API will be changed to take the start address returned
>> from hymmap_map_file and the size of the mapped area instead of the
>> current handle. The handle is not very clear as it is the start
>> address of the mapped area (equivalent to start) on Windows and a
>> pointer to a structure containing this and the size on Unix
>> platforms. Explicitly passing the start address and length will
>> provide a clearer interface.
>>
>> 4. hymmap_capabilities
>>
>> /**
>> * Check the capabilities available for HYMMAP at runtime for the
>> current platform
>> *
>> * @param [in] portLibrary The port library
>> *
>> * @return The capabilities available on this
>> platform
>> * @args
>> HYPORT_MMAP_CAPABILITY_READ
>> * @args
>> HYPORT_MMAP_CAPABILITY_WRITE
>> * @args
>> HYPORT_MMAP_CAPABILITY_COPYONWRITE
>> */
>> I_32 hymmap_capabilities(HYPortLibrary portLibrary)
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[Portlib]Proposal to extend portlib with enhanced mmap functions:
Posted by Paulex Yang <pa...@gmail.com>.
Sorry I forgot to add the prefix just now.
Paulex Yang wrote:
> Hi, all
>
> I raise HARMONY-982
> (https://issues.apache.org/jira/browse/HARMONY-982) about the portlib
> extension on mmap. And here goes my proposal about the extension,
> comments are welcome.
>
> Currently portlib has some mmap support, but the support is limited in
> several ways:
> 1. it only mmap in private(copy_on_write) mode
> 2. it always mmap whole file
> 3. it only accepts filename, but nio needs to map a already opened
> file descriptor
>
> so that the Harmony's mmap is implemented in platform dependent codes
> so far, I think these are good candidates as the portlib extension.
>
> To support the nio's requirement, three current mmap functions need to
> be enhanced - hymmap_map_file, hymmap_unmap_file and
> hymmap_capabilities, one new method is added: hymmap_msync. Please see
> details below:
>
> 1. hymmap_map_file
>
> /**
> * Map a part of file into memory.
> *
> * @param [in] portLibrary The port library
> * @param [in] file The file descriptor/handle of the
> already open file to be mapped
> * @param [in] offset The file offset of the part to be
> mapped
> * @param [in] size The number of bytes to be mapped,
> if zero, the whole file is mapped
> * @param [in] mappingName The name of the file mapping
> object to be created/opened.
> * If a named
> object is not required, this parameter can be specified as NULL
> * @param [in] flags Flags relating to the mapping:
> * @args
> HYPORT_MMAP_FLAG_READ read only map
> * @args
> HYPORT_MMAP_FLAG_WRITE read/write map
> * @args
> HYPORT_MMAP_FLAG_COPYONWRITE copy on write map
> * @args
> HYPORT_MMAP_FLAG_SHARED share memory mapping with other
> processes
> * @args
> HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not
> share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE)
> *
> * @return A pointer to the start of the
> mapped file or NULL is an error has occurred
> */
> void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64
> offset, UDATA size, const char *mappingName, U_32 flags)
>
> This will use CreateFileMapping() and MapViewOfFile() on Windows and
> mmap() on Unix to map the file into the process' address space. In
> both cases, it will return the address to which the file has been mapped.
>
> The memory mapping API's on all platforms require an open handle/file
> descriptor to the file to be mapped.
>
> The mapAddress parameter has been removed from the original
> signature. This was an output parameter from the API containing the
> address at which the file has been mapped. However, this is the
> return value of the function and was therefore duplication.
>
> 2. hymmap_msync
>
> /**
> * Synchronise updates to memory mapped file region with file on disk.
> The call may wait for the file write
> * to complete or this may be scheduled for a later time and the
> function return immediately, depending on
> * the flags setting
> *
> * @param [in] portLibrary The port library
> * @param [in] start Pointer to the start of the
> memory mapped area to be synchronised
> * @param [in] length Length of the memory mapped
> area to be synchronised
> * @param [in] flags Flags controlling the behaviour
> of the function:
> * @args
> HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not
> *
> return until file updated. Note that to achieve this on Windows
> requires the
> *
> file to be opened with the FILE_FLAG_WRITE_THROUGH flag
> * @args
> HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns
> *
> immediately, file will be updated later
> * @args
> HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same
> *
> file be invalidated, so that they can be updated with the values just
> written
> *
> * @return 0 on success, -1 on failure.
> Errors will be reported using the usual port library mechanism
> */
> IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA
> length, U_32 flags)
>
> This function will use msync on Unix and FlushViewOfFile on Windows.
>
> 3. hymmap_unmap_file
>
> /**
> * Unmap previously mapped memory
> *
> * @param [in] portLibrary The port library
> * @param [in] start Pointer to the start of the
> memory mapped area
> * @param [in] size The length of the mapped area
> */
> void hymmap_unmap_file(HYPortLibrary portLibrary, void *start, UDATA
> size)
>
> This existing API will be changed to take the start address returned
> from hymmap_map_file and the size of the mapped area instead of the
> current handle. The handle is not very clear as it is the start
> address of the mapped area (equivalent to start) on Windows and a
> pointer to a structure containing this and the size on Unix
> platforms. Explicitly passing the start address and length will
> provide a clearer interface.
>
> 4. hymmap_capabilities
>
> /**
> * Check the capabilities available for HYMMAP at runtime for the
> current platform
> *
> * @param [in] portLibrary The port library
> *
> * @return The capabilities available on this
> platform
> * @args
> HYPORT_MMAP_CAPABILITY_READ
> * @args
> HYPORT_MMAP_CAPABILITY_WRITE
> * @args
> HYPORT_MMAP_CAPABILITY_COPYONWRITE
> */
> I_32 hymmap_capabilities(HYPortLibrary portLibrary)
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Proposal to extend portlib with enhanced mmap functions:
Posted by Andrew Zhang <zh...@gmail.com>.
Great Paulex,
+1. I agree that mmap family methods should be encapsulated in portlib.
Thanks!
On 7/26/06, Paulex Yang <pa...@gmail.com> wrote:
>
> Hi, all
>
> I raise HARMONY-982 (https://issues.apache.org/jira/browse/HARMONY-982)
> about the portlib extension on mmap. And here goes my proposal about the
> extension, comments are welcome.
>
> Currently portlib has some mmap support, but the support is limited in
> several ways:
> 1. it only mmap in private(copy_on_write) mode
> 2. it always mmap whole file
> 3. it only accepts filename, but nio needs to map a already opened file
> descriptor
>
> so that the Harmony's mmap is implemented in platform dependent codes so
> far, I think these are good candidates as the portlib extension.
>
> To support the nio's requirement, three current mmap functions need to
> be enhanced - hymmap_map_file, hymmap_unmap_file and
> hymmap_capabilities, one new method is added: hymmap_msync. Please see
> details below:
>
> 1. hymmap_map_file
>
> /**
> * Map a part of file into memory.
> *
> * @param [in] portLibrary The port library
> * @param [in] file The file descriptor/handle of the
> already open file to be mapped
> * @param [in] offset The file offset of the part to be
> mapped
> * @param [in] size The number of bytes to be mapped,
> if zero, the whole file is mapped
> * @param [in] mappingName The name of the file mapping
> object to be created/opened.
> * If a named
> object is not required, this parameter can be specified as NULL
> * @param [in] flags Flags relating to the mapping:
> * @args
> HYPORT_MMAP_FLAG_READ read only map
> * @args
> HYPORT_MMAP_FLAG_WRITE read/write map
> * @args
> HYPORT_MMAP_FLAG_COPYONWRITE copy on write map
> * @args
> HYPORT_MMAP_FLAG_SHARED share memory mapping with other
> processes
> * @args
> HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not
> share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE)
> *
> * @return A pointer to the start of the
> mapped file or NULL is an error has occurred
> */
> void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64
> offset, UDATA size, const char *mappingName, U_32 flags)
>
> This will use CreateFileMapping() and MapViewOfFile() on Windows and
> mmap() on Unix to map the file into the process' address space. In both
> cases, it will return the address to which the file has been mapped.
>
> The memory mapping API's on all platforms require an open handle/file
> descriptor to the file to be mapped.
>
> The mapAddress parameter has been removed from the original signature.
> This was an output parameter from the API containing the address at
> which the file has been mapped. However, this is the return value of
> the function and was therefore duplication.
>
> 2. hymmap_msync
>
> /**
> * Synchronise updates to memory mapped file region with file on disk.
> The call may wait for the file write
> * to complete or this may be scheduled for a later time and the
> function return immediately, depending on
> * the flags setting
> *
> * @param [in] portLibrary The port library
> * @param [in] start Pointer to the start of the
> memory mapped area to be synchronised
> * @param [in] length Length of the memory mapped area
> to be synchronised
> * @param [in] flags Flags controlling the behaviour
> of the function:
> * @args
> HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not
> *
> return until file updated. Note that to achieve this on Windows
> requires the
> *
> file to be opened with the FILE_FLAG_WRITE_THROUGH flag
> * @args
> HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns
> *
> immediately, file will be updated later
> * @args
> HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same
> *
> file be invalidated, so that they can be updated with the values just
> written
> *
> * @return 0 on success, -1 on failure.
> Errors will be reported using the usual port library mechanism
> */
> IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA length,
> U_32 flags)
>
> This function will use msync on Unix and FlushViewOfFile on Windows.
>
> 3. hymmap_unmap_file
>
> /**
> * Unmap previously mapped memory
> *
> * @param [in] portLibrary The port library
> * @param [in] start Pointer to the start of the
> memory mapped area
> * @param [in] size The length of the mapped area
> */
> void hymmap_unmap_file(HYPortLibrary portLibrary, void *start, UDATA size)
>
> This existing API will be changed to take the start address returned
> from hymmap_map_file and the size of the mapped area instead of the
> current handle. The handle is not very clear as it is the start address
> of the mapped area (equivalent to start) on Windows and a pointer to a
> structure containing this and the size on Unix platforms. Explicitly
> passing the start address and length will provide a clearer interface.
>
> 4. hymmap_capabilities
>
> /**
> * Check the capabilities available for HYMMAP at runtime for the
> current platform
> *
> * @param [in] portLibrary The port library
> *
> * @return The capabilities available on this
> platform
> * @args
> HYPORT_MMAP_CAPABILITY_READ
> * @args
> HYPORT_MMAP_CAPABILITY_WRITE
> * @args
> HYPORT_MMAP_CAPABILITY_COPYONWRITE
> */
> I_32 hymmap_capabilities(HYPortLibrary portLibrary)
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM