From: Pierre Habouzit <madcoder@debian.org>
To: "Shawn O. Pearce" <spearce@spearce.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Johannes Sixt <johannes.sixt@telecom.at>,
gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH 0/14] fork/exec removal series
Date: Sun, 14 Oct 2007 09:28:49 +0200 [thread overview]
Message-ID: <20071014072849.GD1198@artemis.corp> (raw)
In-Reply-To: <20071014071751.GC1198@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
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 …
[0] http://sourceforge.net/project/shownotes.php?release_id=532062
[...]
* The __thread keyword is honoured.
[...]
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-14 7:29 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 [this message]
2007-10-14 9:10 ` Andreas Ericsson
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=20071014072849.GD1198@artemis.corp \
--to=madcoder@debian.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.sixt@telecom.at \
--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).