public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: "Carlos O'Donell" <carlos@systemhalted.org>
Cc: David Miller <davem@davemloft.net>,
	carlos@redhat.com, 	"Joseph S. Myers" <joseph@codesourcery.com>,
	schwab@linux-m68k.org, thomas_schwinge@mentor.com,
		kkojima@rr.iij4u.or.jp, marcus.shawcroft@linaro.org,
		katsuki.uwatoko@toshiba.co.jp, libc-ports@sourceware.org
Subject: Re: [PATCH] Avoid unnecessary busy loop in __lll_timedlock_wait on ARM.
Date: Tue, 12 Feb 2013 21:41:00 -0000	[thread overview]
Message-ID: <CAN9gPaHv2QvKWcs-jsrbCn_2HczFbU8isi5A09uGYa9sMX0vZg@mail.gmail.com> (raw)
In-Reply-To: <CAN9gPaH-1xwqcnSc2x3jxCiYPs7+83htrfbhvDvzZhAsRNgs3g@mail.gmail.com>

You could try asking Richard Earnshaw...

On Tue, Feb 12, 2013 at 4:41 PM, Daniel Jacobowitz <drow@false.org> wrote:
> It's been too long, sorry.  It may have been necessary solely to
> provide the separate EABI and NPTL versions in sysdeps; you'd have to
> look at e.g. the sysdeps selection order for the LinuxThreads version.
>  It may also be related to the lack of usable atomic primitives,
> pre-EABI.
>
> On Sun, Feb 10, 2013 at 12:54 PM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
>> On Sat, Feb 9, 2013 at 11:56 PM, David Miller <davem@davemloft.net> wrote:
>>> From: "Carlos O'Donell" <carlos@redhat.com>
>>> Date: Sat, 09 Feb 2013 09:55:43 -0500
>>>
>>>> I'd seen the *other* sparc pre-v9 implementation that used 64 global
>>>> locks per-library and that seemed signal unsafe and prone to deadlocks.
>>>
>>> All of these pre-v9 things are signal unsafe and deadlock.
>>>
>>> I thought about doing the kernel atomic emulation other platforms have
>>> adopted, but frankly these cpus are so old and deprecated that they're
>>> not worth doing the work for.
>>>
>>> And by the time we'd propagate all of this infrastructure necessary to
>>> support this kind of scheme, those cpus would be even more outdated.
>>>
>>> Even debian does v9-only build on 32-bit.
>>
>> Eminently practical. Just curious. Thanks for verifying what I suspected.
>>
>> Cheers,
>> Carlos.
>
>
>
> --
> Thanks,
> Daniel



--
Thanks,
Daniel

  reply	other threads:[~2013-02-12 21:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31  8:42 katsuki.uwatoko
2013-02-07 23:33 ` Joseph S. Myers
2013-02-08  0:13   ` katsuki.uwatoko
2013-02-09  4:18   ` Carlos O'Donell
2013-02-09  6:49     ` David Miller
2013-02-09 14:56       ` Carlos O'Donell
2013-02-10  4:56         ` David Miller
2013-02-10 17:55           ` Carlos O'Donell
2013-02-12 21:41             ` Daniel Jacobowitz
2013-02-12 21:41               ` Daniel Jacobowitz [this message]
2013-02-12 21:57               ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN9gPaHv2QvKWcs-jsrbCn_2HczFbU8isi5A09uGYa9sMX0vZg@mail.gmail.com \
    --to=drow@false.org \
    --cc=carlos@redhat.com \
    --cc=carlos@systemhalted.org \
    --cc=davem@davemloft.net \
    --cc=joseph@codesourcery.com \
    --cc=katsuki.uwatoko@toshiba.co.jp \
    --cc=kkojima@rr.iij4u.or.jp \
    --cc=libc-ports@sourceware.org \
    --cc=marcus.shawcroft@linaro.org \
    --cc=schwab@linux-m68k.org \
    --cc=thomas_schwinge@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).