On Aug 11, 1:35pm, t...@panix.com (Thor Lancelot Simon) wrote:
-- Subject: Re: [RFC][PATCH] _UC_TLSBASE for all ports
| On Sat, Aug 11, 2012 at 06:45:12AM +, Christos Zoulas wrote:
| >
| > It is a slippery slope, but I think in this case it is wise to bend.
| > If we cannot reach agreement h
Emmanuel Dreyfus wrote:
> For now if you want to swapcontext() between threads, you can do that
> before calling swapcontext() on amd64, arm, hppa, i386, m68k and vax:
> ctx.uc_flags &= _UC_TLSBASE
I meant this (missing ~):
ctx.uc_flags &= ~_UC_TLSBASE
--
Emmanuel Dreyfus
http
On Sat, Aug 11, 2012 at 16:03:08 -0700, Matt Thomas wrote:
> On Aug 11, 2012, at 10:35 AM, Thor Lancelot Simon wrote:
>
> > On Sat, Aug 11, 2012 at 06:45:12AM +, Christos Zoulas wrote:
> >>
> >> It is a slippery slope, but I think in this case it is wise to bend.
> >> If we cannot reach agre
matthew green wrote:
> i'm confused how the _UC_* interface can be considered "public".
> the whole point of them being _* is that they're private to the
> implementation, and depending on them is wrong.
Yes, _UC_* is out of the standard since there is no uc_field:
http://pubs.opengroup.org/onli
On Aug 11, 2012, at 10:35 AM, Thor Lancelot Simon wrote:
> On Sat, Aug 11, 2012 at 06:45:12AM +, Christos Zoulas wrote:
>>
>> It is a slippery slope, but I think in this case it is wise to bend.
>> If we cannot reach agreement here, consult core.
>
> I see no point bending NetBSD into knots
> > Yes, I dislike it being used, because it breaks perfectly valid
> > assumptions like lwpid being constant across the life time of a thread.
>
> Therefore I do not understand why you oppose the proposal of proposing a
> MI interface to let the user opt out of that bad behavior.
i'm confused h
On Sat, Aug 11, 2012 at 03:42:59PM +0200, Emmanuel Dreyfus wrote:
> Joerg Sonnenberger wrote:
>
> > Yes, I dislike it being used, because it breaks perfectly valid
> > assumptions like lwpid being constant across the life time of a thread.
>
> Therefore I do not understand why you oppose the pro
Joerg Sonnenberger wrote:
> Yes, I dislike it being used, because it breaks perfectly valid
> assumptions like lwpid being constant across the life time of a thread.
Therefore I do not understand why you oppose the proposal of proposing a
MI interface to let the user opt out of that bad behavior
On Sat, Aug 11, 2012 at 01:35:43PM -0400, Thor Lancelot Simon wrote:
> On Sat, Aug 11, 2012 at 06:45:12AM +, Christos Zoulas wrote:
> >
> > It is a slippery slope, but I think in this case it is wise to bend.
> > If we cannot reach agreement here, consult core.
>
> I see no point bending NetB
Thor Lancelot Simon wrote:
> Gee, I wonder why this stuff was removed from the standard.
It seems the biggest problem is that makecontext does not specify
argument types. If you send a pointer on an LP64 machine and the
implementation assumes arguments are int, you are screwed.
--
Emmanuel Dre
On Sat, Aug 11, 2012 at 03:36:28PM +0200, Emmanuel Dreyfus wrote:
>
> Then there is the problem that no spec tells us what swapcontext()
> should do with pthread private context, as returned by pthread_self().
Gee, I wonder why this stuff was removed from the standard.
Thor
On Sat, Aug 11, 2012 at 06:45:12AM +, Christos Zoulas wrote:
>
> It is a slippery slope, but I think in this case it is wise to bend.
> If we cannot reach agreement here, consult core.
I see no point bending NetBSD into knots in this case if the resulting
performance is as bad as Joerg claims
On Aug 11, 5:13pm, m...@netbsd.org (Emmanuel Dreyfus) wrote:
-- Subject: Re: [RFC][PATCH] _UC_TLSBASE for all ports
| > Well, why don't we make it that way then?
|
| We cannot toggle an option that does not exist, so that require adding
| _UC_TLSBASE for ports that miss it. This meets a strong
Christos Zoulas wrote:
> Well, why don't we make it that way then?
We cannot toggle an option that does not exist, so that require adding
_UC_TLSBASE for ports that miss it. This meets a strong opposition for
now.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
matthew sporleder wrote:
> As an aside- I've recently start using gluster and it's very very cool.
On what netbsd and glusterfs versions are you using it?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Aug 11, 12:40pm, m...@netbsd.org (Emmanuel Dreyfus) wrote:
-- Subject: Re: [RFC][PATCH] _UC_TLSBASE for all ports
| Christos Zoulas wrote:
|
| > I could believe that, if the change suggested to make this the default
| > behavior (which some would argue it should be...)
|
| In an ideal world,
As an aside- I've recently start using gluster and it's very very cool.
I'm really pleased with this porting effort.
Thanks manu@!
Joerg Sonnenberger wrote:
> Which begs the question why they (glusterfs) aren't
> using something like libcoro in first place...
It would be nice from you to subscribe to gluster-de...@nongnu.org and
ask there, that would open an insightful discussion.
--
Emmanuel Dreyfus
http://hcpnet.free.fr
Mouse wrote:
> Assuming we go with the "no spec" stance, I think the truth would be
> more like "trying to use contexts across thread boundaries is
> inherently MD, working the way you expect on ports $LIST1, working this
> other way on ports $LIST2, and this third way on ports $LIST3; you're
> d
On Sat, Aug 11, 2012 at 03:37:05AM +0200, Emmanuel Dreyfus wrote:
> Joerg Sonnenberger wrote:
>
> > I don't agree with it being a nasty bug. Heck, document it as limitation
> > if you want. But essentially don't mix *context and pthread in this way,
> > it will create other interesting issues lat
On Sat, Aug 11, 2012 at 09:12:16AM +0200, Emmanuel Dreyfus wrote:
> A glusterfs contributor claims he tested a pure pthread implementation
> against swapcontext+pthread, and he reports the latter is 9 time faster.
Now you are talking about it being a performance optimisation? You are
aware that th
Emmanuel Dreyfus wrote:
> In an ideal world, we would set _UC_TLSBASE by default (as it is today,
> except on powerpc), and we would automatically ignore _UC_TLSBASE when
> l->l_proc->p_nlwps > 1, since we cannot think of a sane usage for that.
Or perhaps do that stuff in swapcontext libc stub?
On Sat, Aug 11, 2012 at 01:50:58PM +0200, Emmanuel Dreyfus wrote:
> Martin Husemann wrote:
>
> > However, for a dummie like me who hasn't seen the code in question, could
> > you please explain how they handle the stack pointer in the context?
>
> - get current ucontext_t wht getcontext();
> - a
Martin Husemann wrote:
> However, for a dummie like me who hasn't seen the code in question, could
> you please explain how they handle the stack pointer in the context?
- get current ucontext_t wht getcontext();
- allocate a stack with malloc(), add it to ucontext_t (uc_stack field)
- call make
On Sat, Aug 11, 2012 at 12:40:44PM +0200, Emmanuel Dreyfus wrote:
> In an ideal world, we would set _UC_TLSBASE by default (as it is today,
> except on powerpc), and we would automatically ignore _UC_TLSBASE when
> l->l_proc->p_nlwps > 1, since we cannot think of a sane usage for that.
I would agr
Christos Zoulas wrote:
> I could believe that, if the change suggested to make this the default
> behavior (which some would argue it should be...)
In an ideal world, we would set _UC_TLSBASE by default (as it is today,
except on powerpc), and we would automatically ignore _UC_TLSBASE when
l->l_
On Aug 11, 11:16am, m...@netbsd.org (Emmanuel Dreyfus) wrote:
-- Subject: Re: [RFC][PATCH] _UC_TLSBASE for all ports
| Christos Zoulas wrote:
|
| > Like it or not most of the world has turned into linux. We can either
| > provide compatibility where possible (and not overly disgusting) to
| > ga
On Thu, Jul 12, 2012 at 10:04:39PM +0200, Reinoud Zandijk wrote:
> Nice! I recently tried out NetBSD-6_BETA2 on my LG NAS (MARVELL_NAS) that has
> a mvsata(4) controller. Currently it only detects my single harddisc but ithe
> machine also has a 2nd harddisc slot and a SATA DVD burner attached.i
>
>> [...], or simply say "tough, it will not work on NetBSD because we
>> refuse to compromise".
> IMO here it is even a worse stance, since we already have the desired
> fix for amd64, i386, m68k, mips, vax, and hppa.
Ah, but is it really a fix?
IMO this all hinges on just what the interface con
Christos Zoulas wrote:
> Like it or not most of the world has turned into linux. We can either
> provide compatibility where possible (and not overly disgusting) to
> gain compatibility with 3rd party code developed for linux, or simply
> say "tough, it will not work on NetBSD because we refuse t
In article <20120810173818.ga8...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Fri, Aug 10, 2012 at 07:31:59PM +0200, Emmanuel Dreyfus wrote:
>> Joerg Sonnenberger wrote:
>>
>> > I maintain that trying to move contexts between threads is an inherently
>> > bad idea and that it is a very in
David Holland wrote:
> (1) What is the C&V of the pertinent standards that describe
> setcontext and getcontext?
As explained in their man page, they are obsolete in the 2004 edition of
POSIX.1, and were removed in the 2008 edition. Standards are of little
help here.
> (2) What is the ostensib
32 matches
Mail list logo
