Philip Guenther wrote:
Well, I am amazed. I guess I just have to do some more investigation into
workarounds for this, as RAM-based tmpfs file systems will get full very
quickly with shared memory segments, and large segments result in high disk
activity when munmap() is called. And SysV shared
On Fri, Jul 15, 2016 at 1:56 AM, wrote:
> Ted Unangst wrote:
>>
>> bytevolc...@safe-mail.net wrote:
>>>
>>> I see where you are coming from, but what I am getting at is, where in
>>> the POSIX standard does it say that it needs to be anywhere in the file
>>> system at all? If it is shared memory,
Ted Unangst wrote:
bytevolc...@safe-mail.net wrote:
I see where you are coming from, but what I am getting at is, where in
the POSIX standard does it say that it needs to be anywhere in the file
system at all? If it is shared memory, then surely this doesn't require
backing up.
Oh. It doesn't
bytevolc...@safe-mail.net wrote:
> I see where you are coming from, but what I am getting at is, where in
> the POSIX standard does it say that it needs to be anywhere in the file
> system at all? If it is shared memory, then surely this doesn't require
> backing up.
Oh. It doesn't have to be a
Theo de Raadt wrote:
Is using ftruncate(2) to lengthen the segment the right way to do it, or
is this yet another stupid limitation of POSIX shared memory?
If you are getting the picture that the standards commitee cobbled
together a bunch of junk and expected a good outcome, you are well
on yo
Ted Unangst wrote:
bytevolc...@safe-mail.net wrote:
When I use ftruncate(2) to actually allocate the segment, the file is as
long as the segment that is allocated.
Even if the file is unlinked before ftruncate(2) is called, enough free
space in the /tmp *file system* is required for the shared
bytevolc...@safe-mail.net wrote:
> When I use ftruncate(2) to actually allocate the segment, the file is as
> long as the segment that is allocated.
>
> Even if the file is unlinked before ftruncate(2) is called, enough free
> space in the /tmp *file system* is required for the shared memory seg
> Is using ftruncate(2) to lengthen the segment the right way to do it, or
> is this yet another stupid limitation of POSIX shared memory?
If you are getting the picture that the standards commitee cobbled
together a bunch of junk and expected a good outcome, you are well
on your way to being on
Ted Unangst wrote:
bytevolc...@safe-mail.net wrote:
Yes, it seems to create files with long names (that have nothing to do
with the template I provide) in the /tmp root.
If it doesn't respect the path or template, what is the point of having
this argument there in the first place, and what is t
bytevolc...@safe-mail.net wrote:
> Yes, it seems to create files with long names (that have nothing to do
> with the template I provide) in the /tmp root.
>
> If it doesn't respect the path or template, what is the point of having
> this argument there in the first place, and what is the point o
Jeremie Courreges-Anglas wrote:
bytevolc...@safe-mail.net writes:
Hello,
I am writing a local server which requires the use of shared memory
objects. Essentially, other applications communicate to this server by
connecting to a UNIX domain socket within the file system.
Occasionally such an a
bytevolc...@safe-mail.net writes:
> Hello,
>
> I am writing a local server which requires the use of shared memory
> objects. Essentially, other applications communicate to this server by
> connecting to a UNIX domain socket within the file system.
>
> Occasionally such an application may require
Hello,
I am writing a local server which requires the use of shared memory
objects. Essentially, other applications communicate to this server by
connecting to a UNIX domain socket within the file system.
Occasionally such an application may require a shared memory buffer to
share large quan
13 matches
Mail list logo
