# 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