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
