search for: threadloc

We can't guarantee what storage duration the caller's request for a thread name has; and in fact, if the caller uses plugin_name() for their thread name, then the moment .unload is called, our threadlocal storage is pointing to la-la-land and we get a nice SEGV while trying to print any debug message. So copy the user's string instead. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/threadlocal.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git...

On 11/16/2017 09:13 PM, Eric Blake wrote: > We can't guarantee what storage duration the caller's request > for a thread name has; and in fact, if the caller uses > plugin_name() for their thread name, then the moment .unload > is called, our threadlocal storage is pointing to la-la-land > and we get a nice SEGV while trying to print any debug message. > So copy the user's string instead. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > src/threadlocal.c | 17 +++++++++++++---- > 1 file changed, 13 insert...

...oblem. (I considered an alternative where we use the saved address to answer nbdkit_peer_name but since that call will in general be used very rarely it doesn't make sense to do the extra work for all callers.) --- server/internal.h | 4 ---- server/sockets.c | 12 ++---------- server/threadlocal.c | 19 ------------------- 3 files changed, 2 insertions(+), 33 deletions(-) diff --git a/server/internal.h b/server/internal.h index 1f72b01..c31bb34 100644 --- a/server/internal.h +++ b/server/internal.h @@ -431,10 +431,6 @@ extern void threadlocal_set_name (const char *name) extern const ch...

...requested data, before memcpy-ing the data to the return buffer. - For OCaml, see the previous commit. Of course I cannot check plugins which may be supplied by others. Credit: Eric Blake for finding the bug. --- server/internal.h | 1 + server/protocol.c | 16 +++++++++------- server/threadlocal.c | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 47 insertions(+), 7 deletions(-) diff --git a/server/internal.h b/server/internal.h index 837cd4a..817f022 100644 --- a/server/internal.h +++ b/server/internal.h @@ -350,6 +350,7 @@ extern void threadlocal_set_sockaddr (const struct...

...ashes or hangs with test-socket-activation (I think I've nailed all the crashes I've seen, but the hang is rather insidious; see my other email https://www.redhat.com/archives/libguestfs/2017-November/msg00139.html) Eric Blake (4): errors: Avoid interleaved errors from parallel threads threadlocal: Copy thread name plugins: Make plugin_name() reliable past unload sockets: Fix lifetime of thread_data src/errors.c | 30 +++++++++++++++++++++++++++++- src/plugins.c | 8 ++++++-- src/sockets.c | 27 ++++++++++++++++++--------- src/threadlocal.c | 17 +++++++++++++---- 4 fil...

Version 1 was here: https://www.redhat.com/archives/libguestfs/2019-April/msg00144.html Version 2 makes a couple of much larger changes: The OCaml patch changes the API of the pread method so it matches what other language bindings are already doing, ie. get the language plugin to return a newly allocated buffer, check it is long enough, copy out the data. The server patch implements a

...that the previous commit makes OCaml like all the other plugins). > > Of course I cannot check plugins which may be supplied by others. > > Credit: Eric Blake for finding the bug. > --- > server/internal.h | 1 + > server/protocol.c | 16 +++++++++------- > server/threadlocal.c | 37 +++++++++++++++++++++++++++++++++++++ > 3 files changed, 47 insertions(+), 7 deletions(-) > > if (cmd == NBD_CMD_READ || cmd == NBD_CMD_WRITE) { > - buf = malloc (count); > + buf = threadlocal_buffer ((size_t) count); > if (buf == NULL) { > -...

..._rwlock_unlock' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x31b): undefined reference to `_imp__pthread_rwlock_wrlock' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x365): undefined reference to `_imp__pthread_rwlock_unlock' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x37): und efined reference to `_imp__pthread_key_create' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0xa5): und efined reference to `_imp__pthread_key_create' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0...

...s user 0m4.520s sys 0m3.567s I think this show that the parallel threading model works for the python plugin as good as for the file plugin. --- plugins/file/file.c | 4 ++-- plugins/python/examples/file.py | 5 ++++- server/plugins.c | 20 ++++++++++++++------ server/threadlocal.c | 7 +++++-- 4 files changed, 25 insertions(+), 11 deletions(-) diff --git a/plugins/file/file.c b/plugins/file/file.c index dc99f992..27316b9f 100644 --- a/plugins/file/file.c +++ b/plugins/file/file.c @@ -170,7 +170,7 @@ file_open (int readonly) return NULL; } - flags...

This fixes the race conditions for me, using the test described here: https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html Rich.

I'm trying to use the Support/ThreadLocal class, and I'm having some trouble because ThreadLocalImpl::getInstance returns a const void*, which I would like to be able to modify. Is there any particular reason this returns a const pointer rather than simply a void pointer? Pthreads and the Windows TLS API both seem to return plain...

...s user 0m4.520s sys 0m3.567s I think this show that the parallel threading model works for the python plugin as good as for the file plugin. --- plugins/file/file.c | 4 ++-- plugins/python/examples/file.py | 5 ++++- server/plugins.c | 20 ++++++++++++++------ server/threadlocal.c | 7 +++++-- 4 files changed, 25 insertions(+), 11 deletions(-) diff --git a/plugins/file/file.c b/plugins/file/file.c index dc99f992..27316b9f 100644 --- a/plugins/file/file.c +++ b/plugins/file/file.c @@ -170,7 +170,7 @@ file_open (int readonly) return NULL; } - flags...

...I think this show that the parallel threading model works for the python > plugin as good as for the file plugin. > --- > plugins/file/file.c | 4 ++-- > plugins/python/examples/file.py | 5 ++++- > server/plugins.c | 20 ++++++++++++++------ > server/threadlocal.c | 7 +++++-- > 4 files changed, 25 insertions(+), 11 deletions(-) > > diff --git a/plugins/file/file.c b/plugins/file/file.c > index dc99f992..27316b9f 100644 > --- a/plugins/file/file.c > +++ b/plugins/file/file.c > @@ -170,7 +170,7 @@ file_open (int readonly)...

...t returns means we still have cases where our detached threads are executing past the point where the main thread has tried to unload the plugin, which is never a nice thing. We may still have more work ahead of us to ensure that we don't unload an in-use plugin. Eric Blake (3): server: Add threadlocal_get_conn server: Add pipe for tracking disconnects server: Add and use nbdkit_nanosleep docs/nbdkit-plugin.pod | 28 +++++++++++++++++ configure.ac | 1 + include/nbdkit-common.h | 1 + server/internal.h | 3 ++ filters/delay/delay.c | 14 ++------- filters/rate/rate....

...locator.cc b/lib/lsan/lsan_allocator.cc index 9bf27b1..190dce8 100644 --- a/lib/lsan/lsan_allocator.cc +++ b/lib/lsan/lsan_allocator.cc @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, SecondaryAllocator> Allocator; static Allocator allocator; -static THREADLOCAL AllocatorCache cache; +static /*THREADLOCAL*/ AllocatorCache cache; void InitializeAllocator() { allocator.Init(); diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc index 7435843..3e6adb6 100644 --- a/lib/msan/msan_allocator.cc +++ b/lib/msan/msan_allocator.cc @@ -33,7 +33...

I'm probably missing something obvious here, but naively, this makes it kind of awkward to have mutable thread local state... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141212/53b577ae/attachment.html>

...index 9bf27b1..190dce8 100644 > --- a/lib/lsan/lsan_allocator.cc > +++ b/lib/lsan/lsan_allocator.cc > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, > AllocatorCache, > SecondaryAllocator> Allocator; > > static Allocator allocator; > -static THREADLOCAL AllocatorCache cache; > +static /*THREADLOCAL*/ AllocatorCache cache; > > void InitializeAllocator() { > allocator.Init(); > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc > index 7435843..3e6adb6 100644 > --- a/lib/msan/msan_allocator.cc > +++ b/...

I am using llvm-2.6. In the online documentation, the signature is GlobalVariable::GlobalVariable ( const Type * Ty, bool isConstant, LinkageTypes Linkage, Constant * Initializer = 0, const Twine & Name = "", bool ThreadLocal = false, unsigned AddressSpace = 0 ) the link to the documenation is http://llvm.org/doxygen/classllvm_1_1GlobalVariable.html There are two constructors given. Second constructor signature is same as the source code. The first one differs though. In the source code the prototype of the co...

...or.cc >> > +++ b/lib/lsan/lsan_allocator.cc >> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >> > AllocatorCache, >> > SecondaryAllocator> Allocator; >> > >> > static Allocator allocator; >> > -static THREADLOCAL AllocatorCache cache; >> > +static /*THREADLOCAL*/ AllocatorCache cache; >> > >> > void InitializeAllocator() { >> > allocator.Init(); >> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >> > index 7435843..3e6adb6 10...

..., Robin Eklind via llvm-dev <llvm-dev at lists.llvm.org> wrote: > declare void @foo() unnamed_addr > global i32 42 Doesn't a global have to be named? The syntax in the IR reference doesn't make it optional: @<GlobalVarName> = [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal] ... Cheers. Tim.