On Jun 1, 2012, at 2:54 PM, Axel Liljencrantz wrote:
>
> 2012/6/1 ridiculous_fish <[email protected]>
> Hello Axel! I am honored to hear from you.
>
> I must thank you for fish. It was (and still is) an inspiration for me, both
> in
> its technical design, and also its user-facing simplicity and elegance
> relative
> to its peers.
>
> Aw man... Thanks! :-)
>
> BTW, I'm guessing you are the person (Craniata?) behind the blog also fount
> at ridiculusfish.com? If so, may I return the favor by saying you are a good
> writer? I learned stuff while being amused when reading the "I Didn't Order
> That, So Why Is It On My Bill" articles among others.
That's me! I'm glad you enjoyed my writings.
(There was a typo in the link; it's http://ridiculousfish.com)
>
> Like I think I said in another mail, I think "black --bold" should work, at
> least on a majority of shells. It's quite possible that it will do something
> ridiculous, like render invisible on a others, though. :-/
Thanks for the tip, I'll experiment with that.
>
> > I would have either moved it to a separate process and communicated over a
> > socket or used cooperative threading, but I guess there is a chance that
> > simply means I'm very, very old.
>
> 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.
>
>
> By the way, initially I viewed halloc with some fear and revulsion, not really
> understanding it. Later I learned to appreciate its cleverness. Was this your
> own idea, or did you learn the technique from somewhere else?
>
> Maybe I should have documented the code better, then. I really think it's a
> pretty wonderful idea, and pretty much the nicest memory management model you
> can find in languages without garbage collecting, IMO. Not my idea at all,
> though. I got it from a very similar setup used by the samba project, but the
> idea's been around for a lot longer than that. I rolled my own version
> because I wanted to be able to call methods when deallocating, sort of like a
> destructor in C++, which wasn't possible in the samba version.
Cool, thanks for the story. It's definitely an idea to remember.
>
> Good to hear about openness. I'm probably doing something wrong on my end,
> though, because I can't seem to find your changes on gitorious. A quick
> glance at the source listing implies that all branches there all use the .c
> extension on all files. Am I doing something stupid?
If you just go to https://gitorious.org/fish-shell/ you should see a day-by-day
breakdown of commits to all forks. Most of the activity is me for the past
several months.
>
>
> Other than the aforementioned syntax-highlighting-on-slow-NFS-shares issue,
> startup was where I noticed the largest performance issues, especially when my
> system was under load. After some tests, I concluded this was due to the sheer
> number of files touched: every command requires a check for an autoloading
> function, in multiple directories. My Core i5 may smoke your Pentium II, but
> my
> 5400 RPM hard disk sure won't!
>
> If I remember correctly, fish will stat all individual loadable files at
> startup and after that will only check the modification date on the directory
> the files live in, so the stat count during use should be fairly manageable.
> Your interning of share/{functions,completions} should help reduce the number
> of stat calls during startup, but the way it's done right now has side
> effects, like we've noticed. Like I said yesterday, I believe it's possible
> to implement this feature as a fallback after searching
> $fish_function_path/$fish_completion_path, and that way you can get the
> memory savings without any of the weird side effects. The only downside would
> be the loss of discoverability - I think that checking out the completion
> files in the shared-directory is an excellent way to get started at writing
> your own completions, which I in the past found to be the most common way to
> lure people into becoming fish contributors.
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.
_fish------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
