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

2015-09-06 Thread Charles Forsyth
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)

2015-09-06 Thread 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

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

2015-09-06 Thread erik quanstrom
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)

2015-09-06 Thread cinap_lenrek
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-06 Thread Giacomo Tesio
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)

2015-09-06 Thread Charles Forsyth
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)

2015-09-06 Thread erik quanstrom
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)

2015-09-06 Thread cinap_lenrek
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)

2015-09-06 Thread erik quanstrom
> 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