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
next prev parent 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).