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
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();
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.
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
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
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
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
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
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
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
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
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
... 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
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
> implementation doesn't appear correct for shared-memory procs.
> i think there are two issues
> - locking is unnecessary. the only preemptable unit of
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 =
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
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
>
> 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
19 matches
Mail list logo