You are right, that one is not needed any more. I used CPU_AND to copy cpuset_t
(dest = src & src; and only now noticed that memcpy is "recommend" way to copy
it :). And since I was adding one, I added a few more of them. Description is
from man CPU_SET, so glibc, yes. E.g. CPU_AND_S setsize is
From: Justin Cinkelj
Committer: Nadav Har'El
Branch: master
libc: new thread should inherit parent thread cpu pinning
Fixes #761
Signed-off-by: Justin Cinkelj
Message-Id: <20161129141222.11595-3-justin.cink...@xlab.si>
---
diff --git a/libc/pthread.cc b/libc/pthread.cc
--- a/libc/pthread.cc
From: Justin Cinkelj
Committer: Nadav Har'El
Branch: master
loader: start do_main_thread unpinned
main_cont is pinned to CPU 0. The #761 asks for pthread_create
to use caller thread CPU pinning for new thread
(in case there is no explicit pinning requested with pthread_attr_t).
Fix for #761 re
From: Justin Cinkelj
Committer: Nadav Har'El
Branch: master
tests: new pthread should inherit parent CPU affinity
New pthread should have CPU affinity requested be cpuset in
attributes. If explicit cpu pinning is not requested, than parent
thread CPU pinning should be used.
Signed-off-by: Jus
I've committed the three other patches in this series, but this one appears
to be no longer needed.
Did you want me to apply it anyway?
Can you say a few words about why you wanted this specific functions and
where you got their description? (are they inspired by what glibc have in
sched.h?)
--
On Thu, Oct 27, 2016 at 3:06 PM, Benoît Canet <
benoit.canet.cont...@gmail.com> wrote:
> We want the init of the elf object to use
> the tls defined when the new thread is started.
>
> Delay this initialization.
>
> Signed-off-by: Benoît Canet
> ---
> core/app.cc| 4 +++-
> core/elf.cc
On Wed, Nov 30, 2016 at 1:18 PM, Rick Payne wrote:
>
> > On 30 Nov 2016, at 07:07, Nadav Har'El wrote:
> >
> > I just sent to the mailing list a patch for this bug. Can you please try
> it out?
>
> That works, thanks.
>
You're welcome, and thank you for the excellent detective work which
uncove
> On 30 Nov 2016, at 07:07, Nadav Har'El wrote:
>
> I just sent to the mailing list a patch for this bug. Can you please try it
> out?
That works, thanks.
Rick
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this gro
From: Nadav Har'El
Committer: Nadav Har'El
Branch: master
pthread: pthread_spin_lock must not disabled preemption
Our pthread_spin_lock implementation incorrectly used the kernel spinlock
implementation which disabled preemption, which is both inappropriate and
unnecessary for application code
On 11/30/2016 01:05 PM, Nadav Har'El wrote:
Our pthread_spin_lock implementation incorrectly used the kernel spinlock
implementation which disabled preemption, which is both inappropriate and
unnecessary for application code.
Ironically, after commit 930cb83d914796893746d5d7f7f9cf6df37db5e6,
p
On Wed, Nov 30, 2016 at 11:52 AM, Nadav Har'El wrote:
> Thanks. This is a real bug in pthread_spin_lock(). I opened
> https://github.com/cloudius-systems/osv/issues/814 for this.
>
>
I just sent to the mailing list a patch for this bug. Can you please try it
out?
Thanks,
Nadav.
--
You received
Our pthread_spin_lock implementation incorrectly used the kernel spinlock
implementation which disabled preemption, which is both inappropriate and
unnecessary for application code.
Ironically, after commit 930cb83d914796893746d5d7f7f9cf6df37db5e6,
pthread_spin_lock() became completely unusable: A
Thanks. This is a real bug in pthread_spin_lock(). I opened
https://github.com/cloudius-systems/osv/issues/814 for this.
--
Nadav Har'El
n...@scylladb.com
On Wed, Nov 30, 2016 at 3:21 AM, Rick Payne wrote:
>
> I kept track of previous calls to resolve_pltgot to see where the last
> call was wh
13 matches
Mail list logo