From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Error reporting capabilities for libxc Date: Mon, 23 Oct 2006 15:04:41 -0500 Message-ID: <453D2059.5070809@us.ibm.com> References: <3AAA99889D105740BE010EB6D5A5A3B202A3B1@paddington.ad.cl.cam.ac.uk> <20061023180017.GE25795@redhat.com> <453D1554.8000202@us.ibm.com> <20061023192753.GG25795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061023192753.GG25795@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: > I'm doing this on FC6 - the __thread annotation is the same approach > used in libc for the per-thread errno variable, hence why I chose it > try it initially. The version are: > > glibc-2.5-3 > gcc-4.1.1-30 > > >> I've found in the past that __thread can have problems when using shared >> libraries (the exact instance was a Python binding). >> > > I've not explicitly tested this integrating with the python bindings > and ensuring the correct per-thread operation. > Will the python bindings actually load? In the past, I've not been able to import a module that contains __thread variables. Regards, Anthony Liguori > One further issue I've thought of is that the __thread annotation does > not provide any way to do cleanup when a thread exists. Fine if the > per-thread variable is a simple scalar, but not so good if its a char * > since I think it'll leak memory. So I think I may have no choice by to > re-write with pthread_getspecific(), since that allows registration > of a cleanup function to free memory. > > Regards, > Dan. >