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

[Charles Forsyth <charles.forsyth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On 6 September 2015 at 00:38, <cinap_lenrek@felloff.net> 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 cases, and indeed
preferable
to a strictly-local allocation for certain types of data. For instance, to
tag a process
with (say) an application-defined Proc structure, that structure must be at
the same slot in
every process to allow it to be found.

With that scheme, there isn't any need for the lock, because only one
process can call it. If the cells were instead allocated using a strictly
local free list or bitmap,
which would be possible, there still wouldn't be any need for the lock,
so the original thinking is still obscure.

i think the logic in tprivalloc is what was intended.
>

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.

[-- Attachment #2: Type: text/html, Size: 2706 bytes --]