sm_alloc_lpsz
| Definition: |
include builtins\ipc.e
atom pSharedMem = sm_alloc_lpsz(string name, string s) |
| Description: |
This routine attempts to allocate a contiguous block of shared memory long enough to store the string s,
that will be identified by the string name.
Returns: the address of the block of memory identified by name, filled with the specified string. If a block of memory that is identified by name already exists, or the memory cannot be allocated, then sm_alloc_lpsz() returns one of the predefined error values. |
| pwa/p2js: | Not supported |
| Comments: |
If another block of memory exists, that is already identified by name, the memory will not be allocated.
Before attempting to create a new block of memory, sm_open() can be called to find out if the name already exists. Each application must call sm_close() to close its handle to the shared memory. A block of shared memory will continue to exist until all handles to it have been closed. The parameter s is actually a sequence, rather than a string, to facilitate accepting the output of serialize() directly, which happens to be a dword-sequence that only contains integers in the range 0..255, as should be the case for any other non-string values that get passed to s. |
| Example: |
include builtins\ipc.e
include builtins\serialize.e
sequence s = {"Pete",{-1,0,1},PI,-PI}
atom pMem = sm_alloc_lpsz("test",serialize(s))
--atom pMem = sm_open("test") -- (if a separate process)
?deserialize(pMem,-1)
-- shows {"Pete",{-1,0,1},3.141592654,-3.141592654}
sm_close("test")
Obviously, in a client/server scenario, the sm_close() corresponding to the sm_alloc_lpsz() in the server should not occur before the sm_open() in the client, but otherwise, if there are two, it does not matter which sm_close() happens first. |
| See Also: | sm_create, sm_open, sm_close, serialize, deserialize |