On Mon, Oct 23, 2006 at 03:04:41PM -0500, Anthony Liguori wrote:
> 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.
Yes, that worked just fine. I tested using xend/xm to validate the saner
error handling behaviour for invalid kernels, eg
# xm create crash
Using config file "crash".
Error: [2, 'Invalid kernel', "Kernel ELF type '3' does not match Xen type '2'"]
# xm create crash
Using config file "crash".
Error: [2, 'Invalid kernel', "Kernel ELF architecture '3' does not match Xen
architecture '62' (x86_64)"]
# xm create crash
Using config file "crash".
Error: [2, 'Invalid kernel', 'Not a valid ELF or raw kernel image']
Given the notes in the GCC docs about needing support from libdl.so,
libc.so & libthread.so I suspect one of the libraries in your stack
was not fully compliant with the __thread specs.
> >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.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home