On Sun, Oct 14, 2007 at 02:58:57AM +0000, Shawn O. Pearce wrote:
Show 22 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sat, 13 Oct 2007, Shawn O. Pearce wrote:
> >
> > > Since builtin-pack-objects now accepts (limited) pthread support,
> > > perhaps this should be implemented in terms of pthread support when
> > > pthreads are available?
> >
> > Falling back to fork() when no pthreads are available? Yes, that makes
> > sense.
> >
> > It might also (marginally) speed up operations, since the switches between
> > threads are cheaper than those between processes, right?
>
> Usually. If we have a large virtual address space (say due to
> opening a bunch of packfiles and reading commits out of them into
> struct commit* thingies) and the OS does a giant copy of the page
> tables during fork() then the pthread creation should be a heck of
> a lot cheaper.
>
> But we most definately *must* continue to support fork() for the
> async functions. Its the most common interface available on one
> of our biggest platforms (UNIX).
Yeah that, and the fact that many of the git modules aren't
thread-safe (some modules have static buffers strbuf's or caching
variables) and should be used with care.
The trivial way is to add a __thread keyword to make them TLS
variables, though, it's not really a step in the direction of
portability, and last time I looked at it, mingw didn't had TLS support,
not sure if msys has. Though, if Msys has, it's worth using, and we
could require that targets using the fancy pthread thingy should also
have some fancy TLS, or use fork().
Portability for such issues, would be to use pthread_key_* and
pthread_{get,set}specific, and those are a hell of a sucky API.Pierre Habouzit <madcoder@debian.org>