git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Pierre Habouzit <madcoder@debian.org>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <johannes.sixt@telecom.at>,
	gitster@pob
Subject: Re: [PATCH 0/14] fork/exec removal series
Date: Sun, 14 Oct 2007 11:10:56 +0200	[thread overview]
Message-ID: <4711DD20.8070600@op5.se> (raw)
In-Reply-To: <20071014072849.GD1198@artemis.corp>

Pierre Habouzit wrote:
> On dim, oct 14, 2007 at 07:17:51 +0000, Pierre Habouzit wrote:
>> On dim, oct 14, 2007 at 07:12:39 +0000, Pierre Habouzit wrote:
>>>   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
>>   Okay forget it, mingw and msys are one and the same *g*.
>>   So well, maybe threading isn't such a so great idea :/
> 
>   And again last time I checked it was still a mingw 3.x in debian, now
> that it's 4.2.1 it seems to support __thread (but not
> __declspec(thread)) and their changelog seems to confirm that fact [0].
> 
>   So the question holds again, do we require pthread-using targets to
> support TLS ? It feels sane and right to me, but …
> 

To me it's a sane place to start. As time goes by and people on non-TLS
capable systems come along that need the functionality (or the speedup;
fork() is expensive on some systems), they can probably implement it
themselves or at least give voice to the fact that they need it.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2007-10-14  9:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-13 20:06 [PATCH 0/14] fork/exec removal series Johannes Sixt
2007-10-13 20:06 ` [PATCH 01/14] Change git_connect() to return a struct child_process instead of a pid_t Johannes Sixt
2007-10-13 20:06   ` [PATCH 02/14] Use start_command() in git_connect() instead of explicit fork/exec Johannes Sixt
2007-10-13 20:06     ` [PATCH 03/14] Use start_command() to run content filters " Johannes Sixt
2007-10-13 20:06       ` [PATCH 04/14] Use run_command() to spawn external diff programs instead of fork/exec Johannes Sixt
2007-10-13 20:06         ` [PATCH 05/14] Use start_comand() in builtin-fetch-pack.c instead of explicit fork/exec Johannes Sixt
2007-10-13 20:06           ` [PATCH 06/14] Have start_command() create a pipe to read the stderr of the child Johannes Sixt
2007-10-13 20:06             ` [PATCH 07/14] upload-pack: Use start_command() to run pack-objects in create_pack_file() Johannes Sixt
2007-10-13 20:06               ` [PATCH 08/14] Add infrastructure to run a function asynchronously Johannes Sixt
2007-10-13 20:06                 ` [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c Johannes Sixt
2007-10-13 20:06                   ` [PATCH 10/14] upload-pack: Move the revision walker into a separate function Johannes Sixt
2007-10-13 20:06                     ` [PATCH 11/14] upload-pack: Run rev-list in an asynchronous function Johannes Sixt
2007-10-13 20:06                       ` [PATCH 12/14] t0021-conversion.sh: Test that the clean filter really cleans content Johannes Sixt
2007-10-13 20:06                         ` [PATCH 13/14] Avoid a dup2(2) in apply_filter() - start_command() can do it for us Johannes Sixt
2007-10-13 20:06                           ` [PATCH 14/14] Use the asyncronous function infrastructure to run the content filter Johannes Sixt
2007-10-14  3:07                             ` Johannes Schindelin
2007-10-14  9:39                               ` Johannes Sixt
2007-10-14 17:14                               ` [PATCH amend " Johannes Sixt
2007-10-14 17:08                 ` [PATCH amend 08/14] Add infrastructure to run a function asynchronously Johannes Sixt
2007-10-14  0:57   ` [PATCH 01/14] Change git_connect() to return a struct child_process instead of a pid_t Johannes Schindelin
2007-10-14  9:40     ` Johannes Sixt
2007-10-14 17:10       ` Johannes Schindelin
2007-10-14  2:11 ` [PATCH 0/14] fork/exec removal series Shawn O. Pearce
2007-10-14  2:50   ` Johannes Schindelin
2007-10-14  2:58     ` Shawn O. Pearce
2007-10-14  7:12       ` Pierre Habouzit
2007-10-14  7:17         ` Pierre Habouzit
2007-10-14  7:28           ` Pierre Habouzit
2007-10-14  9:10             ` Andreas Ericsson [this message]
2007-10-14 17:09         ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4711DD20.8070600@op5.se \
    --to=ae@op5.se \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=gitster@pob \
    --cc=johannes.sixt@telecom.at \
    --cc=madcoder@debian.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).