In any case, an implementation along the lines of tprivalloc seems ok,
and passes my naive test program.
#include
#include
static Lock privlock;
static int privinit;
static u32int privmap;
extern void **_privates;
extern int _nprivates;
void **
privalloc(void)
{
void **p;
int i;
lock(&priv
On 7 September 2015 at 01:30, erik quanstrom wrote:
> unless by name an entry in a table shared by the set of memory sharing
> processes is what is meant
the table isn't shared. the address of the table is the same, but the
underlying memory is private,
and indeed can't be shared (there isn't a
privalloc doesn't create a name either. unless by name an entry in a table shared by the set of memory sharing processes is what is meant. this is not helpful though because I was specifically addressing the case where it was just process private.
- erik
On Sep 6, 2015 1:21 PM, Charles Forsyth
On 6 September 2015 at 19:21, wrote:
> manpage, might just get rid of privfree() itself. globally allocate
> the slots one after another.
>
it's useful to be able to reset some or all of the state in a supervisory
process after a failure and restart.
the tprivalloc/tprivfree [+bug fix] approach
On 6 September 2015 at 16:02, erik quanstrom wrote:
> a slot of local interest? doesn't malloc serve that purpose well enough?
It doesn't create a name for a per-process global.
instead of trying to explain these semantics of privfree() in the
manpage, might just get rid of privfree() itself. globally allocate
the slots one after another.
--
cinap
> probably, since a shared bitmap would need a lock and allow
> any process to allocate a slot, which could then either be broadcast
> to allow per-process tagging (as above), or allocation of a slot of only
> local interest. even so, tprivfree is incomplete.
a slot of local interest? doesn't mal
On 6 September 2015 at 00:38, wrote:
> is privfree() broken? it appears it chains the slots together,
> but only the calling process will get a correct chain.
>
The only way it works is to have a main process allocate and free slots for
use by
all participants, which is a workable scheme in many
On Sat Sep 5 23:33:50 PDT 2015, cinap_len...@felloff.net wrote:
> hey charles!
>
> is privfree() broken? it appears it chains the slots together,
> but only the calling process will get a correct chain. the chain
> head (privs) is shared (in bss) and seen by all process so the
> others will get c
2015-09-05 20:47 GMT+02:00 erik quanstrom :
> > May be my problem is that p is global in my case?
>
> global variables are in the bss, and thus shared. p will have
> the same value in each thread, but *p should point into the
> stack, and thus the same virtual address will be mapped to
> different
hey charles!
is privfree() broken? it appears it chains the slots together,
but only the calling process will get a correct chain. the chain
head (privs) is shared (in bss) and seen by all process so the
others will get corrupted chains (chain link is private) no?
i wonder what the intended use f
On 5 September 2015 at 15:03, Giacomo Tesio wrote:
> For extra safety I added an assert(*p == nil) just after rfork, and after
> a few (apparently?) successful spawns, the assert fails.
The stack is a logical copy of the parent process's stack at rfork, even
with RFMEM, since the stack's not sh
it doesnt matter. p is a pointer to a pointer. the whole
idea of privalloc() is to give you a memory locaiton that
when *dereferenced* can yield different *values* under different
processes, tho the *address* is the same, so it can be passed
arround.
--
cinap
> May be my problem is that p is global in my case?
global variables are in the bss, and thus shared. p will have
the same value in each thread, but *p should point into the
stack, and thus the same virtual address will be mapped to
different physical pages of memory.
however, if *p is assigned t
Nice example thanks.
May be my problem is that p is global in my case?
Giacomo
Il 05/Set/2015 18:50, "erik quanstrom" ha scritto:
> by the way, the following program runs without asserting for me
> with or without the waits.
>
> - erik
>
> ---
>
> #include
> #include
>
> void
> task(void **p)
by the way, the following program runs without asserting for me
with or without the waits.
- erik
---
#include
#include
void
task(void **p)
{
assert(*p == nil);
*p = (void*)(uintptr)getpid();
}
void
spawn(void (*t)(void**), void **p)
{
int pid;
switch(pid = r
On Sat Sep 5 07:06:44 PDT 2015, giac...@tesio.it wrote:
> 2011-05-20 3:30 GMT+02:00 erik quanstrom :
uh, wow. i hope this wasn't my mailer dragging the past up.
> > one note is that while i'm aware of privalloc(2), i didn't use it. the
> > implementation doesn't appear correct for shared-memo
... and given getpid(2) implementation, a pid based table could be quite
expensive, since MyStruct is accessed very very often.
2015-09-05 16:03 GMT+02:00 Giacomo Tesio :
> 2011-05-20 3:30 GMT+02:00 erik quanstrom :
>
>> one note is that while i'm aware of privalloc(2), i didn't use it. the
>> i
18 matches
Mail list logo