public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com>
To: Eric Christopher <echristo@redhat.com>
Cc: Zack Weinberg <zack@codesourcery.com>,
	Richard Henderson <rth@redhat.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [basic-improvements] Remove __gthread_key_dtor
Date: Mon, 04 Nov 2002 17:08:00 -0000	[thread overview]
Message-ID: <20021105010819.GC8919@egil.codesourcery.com> (raw)
In-Reply-To: <1036442469.1509.22.camel@ghostwheel>

On Mon, Nov 04, 2002 at 12:41:08PM -0800, Eric Christopher wrote:
> > 
> > There needs to be just one version of these variables, but gthr.h is
> > included all over the place - this needs to go out-of-line, into a
> > libgcc.a extra part, probably along with the code that uses it.
> 
> Hrm. I was noticing that other ports use this method and that's why I
> did - I also didn't see a way for it to work otherwise since there's no
> general .c mechanism for it.

You create a .c file in config/ARCH, and mention it in the LIB2ADD
variable in your t-TARGET file.

> > I take it there can be only 256 threads?
> 
> Heh. Threads? No. I've got semaphores and only semaphores.

Er, what's this GetThreadId() then?

> > There is no requirement that dtor be nonzero, and you threw away its
> > value; this will cause memory leaks.  You're going to need to find
> > some way to get a callback run at thread exit time.  And that callback
> > can do the clear-out-the-value thing.
> 
> hrm. If I could do that I could also free semaphores which would help me
> avoid the 253 limit that I currently have. I was under the impression
> that this was not possible though - at least not without rewriting the
> machinery. 

If the underlying API doesn't support this, you're out of luck.  But
if there _is_ a way to get a callback run at thread exit time, you can
just set one up in your init-once routine.

Take a look at gthr-vxworks.h, config/vxlib.c, and config/t-vxworks on
the gcc-3_4-basic-improvements-branch (after I commit them, which will
happen in the next twenty minutes or so) -- they should give you some
ideas.

zw

  reply	other threads:[~2002-11-05  1:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-29 14:33 Zack Weinberg
2002-10-29 23:50 ` Mark Mitchell
2002-10-31 11:18 ` Richard Henderson
2002-10-31 11:42   ` Zack Weinberg
2002-10-31 13:02     ` Richard Henderson
2002-10-31 13:20       ` Zack Weinberg
2002-10-31 13:57         ` Eric Christopher
2002-10-31 16:12           ` Zack Weinberg
2002-11-04 12:11             ` Eric Christopher
2002-11-04 17:08               ` Zack Weinberg [this message]
2002-11-04 18:19                 ` Eric Christopher
2002-10-31 12:04   ` Jason R Thorpe
2002-10-31 13:59     ` Eric Christopher

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=20021105010819.GC8919@egil.codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=echristo@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rth@redhat.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).