Re: Wislist for Linux from the mold linker's POV

[наб]

On Fri, Nov 29, 2024 at 04:25:09PM +0900, Rui Ueyama wrote:
> On Fri, Nov 29, 2024 at 4:17 PM наб <nabijaczleweli@xxxxxxxxxxxxxxxxxx> wrote:
> > Hi! one quick q to clarify, if you don't mind.
> >
> > On Thu, Nov 28, 2024 at 11:52:35AM +0900, Rui Ueyama wrote:
> > > - exit(2) takes a few hundred milliseconds for a large process
> > >
> > > I believe this is because mold mmaps all input files and an output
> > > file, and clearing/flushing memory-mapped data is fairly expensive.
> > >
> > > To avoid this overhead, mold currently forks a child process, lets the
> > > child handle the actual linking task, and then, as soon as the child
> > > closes the output file, the parent exits (which takes no time since
> > > the parent is lightweight). Since the child is not an interactive
> > > process, it can afford to take its time for exit. While this works, I
> > > would prefer to avoid it if possible, as it is somewhat a hacky
> > > workaround.
> > Sooo am I reading it right that the output file is not valid when mold exits,
> > since you seem to be exiting /during/ exit->munmap->msync,
> > while the contents of the file are undefined,
> > so mold -o whatever && ./whatever is not valid
> > (while mold -o whatever then ./whatever later is)?
> No worries. The child mold process unmaps and closes an output file
> before notifying the parent mold process of completion. Therefore, the
> output file is guaranteed to be complete and valid when the parent
> exits.
Ah, that's alright then, naturally. To me, given the context in the
first para, the original phrasing read a little as-if mold did
  parent                                             exit() -> output undefined -> ok
        \                                           / a few hundred milliseconds  /
        child -> open() -> mmap() -> link -> close() ->    msync()/munmap()/exit()

Thanks :)

Attachment: signature.asc
Description: PGP signature