From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12763 invoked by alias); 5 Oct 2008 20:12:37 -0000 Received: (qmail 12754 invoked by uid 22791); 5 Oct 2008 20:12:37 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1-g19.free.fr (HELO smtp1-g19.free.fr) (212.27.42.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Oct 2008 20:11:55 +0000 Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id 58C9D1AB33C for ; Sun, 5 Oct 2008 22:11:52 +0200 (CEST) Received: from [192.168.0.2] (gre92-6-82-231-206-104.fbx.proxad.net [82.231.206.104]) by smtp1-g19.free.fr (Postfix) with ESMTP id 2F7211AB325 for ; Sun, 5 Oct 2008 22:11:52 +0200 (CEST) Message-ID: <48E91F80.5080809@yahoo.fr> Date: Sun, 05 Oct 2008 20:12:00 -0000 From: =?ISO-8859-1?Q?S=E9bastien_Kunz-Jacques?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: pthreads-win32 2.8.0, stack alignment, and SSE code References: <48E8B399.502@yahoo.fr> <48E8C3B8.2080709@lisha.ufsc.br> <48E8D34F.4@yahoo.fr> <48E906BD.5090304@lisha.ufsc.br> <48E90CB1.2040000@yahoo.fr> <48E91469.3060508@lisha.ufsc.br> In-Reply-To: <48E91469.3060508@lisha.ufsc.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2008/txt/msg00059.txt.bz2 Ramiro Polla a écrit : >> Ramiro Polla a écrit : >> I didn't express myself very well then. I meant to say: "The overhead >> really is negligible. Starting the thread takes much longer, so the >> overhead in aligning the stack gets hidden away in the delay to start >> the thread". In that case always aligning the stack in threadStart would save some headaches to a lot of people, I think. While googling about these issues I found mentions of the ffmpeg case you talked about; that is because of them that I found the correct attribute to align the stack. some mplayer codecs seem to have trouble with these multithreaded alignment issues too. If for some reason it is not desirable to patch the lib, would it be possible to have some easy to see disclaimer added about this problem somewhere?