David Gwynne <da...@gwynne.id.au> wrote: > from yet another perspective, broad use of a common lock can end up > hurting in the long run because you may end up where everything is > serialised and you have to go back and do a ton of work again anyway. > > > I think the theory is ps_kbind_addr is fixed to a shared address space > > in "pr", if you are threaded there is only one ps_kbind_addr for all the > > processes "p" sharing that address space. > > yes. > > > And execve() uses single_thread_set, which means you can't race? > > also yes. the value starts at 0, updates are serialised by the > mutex, and the updates don't produce invalid intermediate state.
so what is the mutex for? Is this being over-designed? On a shared address space, ld.so will be entered before we thread, straight out of execve. I don't think we have constructors starting threads, that would be very bad right? So there are two cases -- static binary and dynaamic. On one address space, kbind is only called once, and there is only one attempt, and any other attempt should kill you, because you are doing it manual & wrong. <-- is this correct, guenther?
