Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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();

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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.

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

> 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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

... 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

[9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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 =

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

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 >

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

> 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