search for: threadlocal

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 a...

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 insertio...

...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 char...

...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 so...

...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 files...

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+0xf...

...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 v...

...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.c...

...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,7...

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/li...

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 cons...

...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 1006...

..., 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.