Re: [Fish-users] Fish-users Digest, Vol 65, Issue 6

[Axel L. <lil...@gm...>]

2012/6/5 ridiculous_fish <cor...@ri...>

>
> On Jun 1, 2012, at 2:54 PM, Axel Liljencrantz wrote:
>
>
> 2012/6/1 ridiculous_fish <cor...@ri...>
>
> ...

> Or maybe wise. Combining threads with forks is very...delicate, and had I
>> appreciated just how delicate it was, I might not have attempted it. It
>> can be
>> done safely and portably, and I claim to have done so, but it does
>> require some
>> contortions.
>>
>
> Would you say it is delicate as in the code is still fragile, or only that
> it was a long journey to get it to a robust state? Can you give some
> pointers to parts of the code that are less obvious?
>
>
> It's delicate the same way signal handlers are delicate. The POSIX spec
> says that, if you call fork while you have multiple threads, the child may
> only call async-safe functions.
>
> An example of a function I had to change is  launch_process(), which fish
> calls after fork to actually execute the new process, via execve.  fish
> uses wide character strings everywhere, but execve wants a narrow-string
> path, so fish needs to convert from wide to narrow, via wcs2str. But that
> may allocate memory, which is not allowed. So now the parent performs the
> conversion before the fork, and the child passes it directly to execve().
>
> In practice, I think the risk is minimal. glibc's malloc is safe to use
> after fork (via pthread_atfork), and I suspect the same is true on BSDs and
> OS X as well. I also wrote a test case and was unable to force any failure
> (it's included in fish_tests.cpp, but disabled).
>
> Nevertheless, I want to be compliant. There's a few conventions I
> established:
>
> - Internal functions that are async safe have the _safe prefix or suffix,
> e.g. format_size_safe.
> - There's a macro ASSERT_IS_NOT_FORKED_CHILD which functions can use if
> they must not be called in a forked child.
> - Functions designed to be called after fork() are being migrated to a new
> file 'postfork.cpp'.
> - If we really get into serious trouble, we can put it into a mode where
> it waits for all threads to exit before calling fork, which would have
> decreased performance in some cases but be very safe.
>
> I am optimistic that all of these contortions can go away once we migrate
> to posix_spawn. In case you are unfamiliar, posix_spawn takes a path to
> execute and a bundle of "actions" (close this fd, dup that fd to there,
> join this process group, etc.) and does the logical equivalent of fork,
> actions, exec. The advantage is that error codes like ENOEXEC, are returned
> to the parent, not the child. It should be a significant simplification.
>

Thanks for the overview.


> Yes, the existing functions and completions serve as excellent sample code!
>
> By the way, I've disabled the whole intern'd function thing for the next
> release.
>

Do you have measurements of how much this helps? Would be interesting to
know if this actually improves things enough to be worth pursuing.

BTW, hope you have fun at the WWDC. I'm more of a backend guy, but I know a
bunch of people at work have been looking forward to it.

Axel