public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@callisto.canberra.edu.au>
To: Pthreads-Win32 list <pthreads-win32@sources.redhat.com>
Subject: Re: Re: Static link (MSVC), alteration proposal
Date: Thu, 31 Mar 2005 08:29:00 -0000	[thread overview]
Message-ID: <1112257786.19990.180.camel@desk.home> (raw)
In-Reply-To: <1112254930.d6fc30c99fd62@mail.bg>

On Thu, 2005-03-31 at 10:42 +0300, Dimitar Panayotov wrote:
> > Hi,
> > Thanks for the changes and the explanations. They
> > certainly fill a gap.
> 
> Hello, Ross, and thank you for your detailed attention you
> attested.
> 
> > The PTW32_BUILD conditional was added by me. I've never
> > built the
> > library statically, and don't test this side of things.
> > This is because
> > the library is essentially designed for dynamic linking
> 
> No, PTW32 is written very clever.
> 

Much has been added or modified since John Bossom contributed his
original version of the library, but a fundamental design feature from
that version that has been kept is the ability of Win32 threads to call
POSIX routines, and thus become pseudo POSIX threads. This requires some
behind-the-scene work to manage, and it's important that cleaning up be
done when these threads exit, or the process exits. For this to be
seamless and transparent to an application that uses the library ideally
requires the dllMain feature.

> 1. Since the sources are written in a way which relies on
> the headers to determine the type of linkage of all the
> PTW32 functions, then actually everything is up to the
> headers.
> 2. Since all the sources are combined in single one --
> <pthread.c>, things are quite easy, because you only need
> to add <pthread.c> to your project (or give to it a
> separate entry in the Makefile), it will be compiled, and
> then pthread.obj will be included in the final link, and
> that's it.
> 
Yes, you can do that. This was how John's original version was
presented. Then I split the routines out into separate modules so that a
static library could be built such that any static linking exe could
include only those routines it needed (for embedded applications). But
apparently all of the target compilers include options to do this
automatically anyway. The monolithic pthread.c file is intended
primarily to reassemble all of the modules into a single compilation
unit in an attempt to maximise inlining of functions within the library.

> I admit that the style of the people who have written PTW32,
> is professional.

All of the contributions to the library have been absolutely awesome.

Regards.
Ross


      reply	other threads:[~2005-03-31  8:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30 14:15 Dimitar Panayotov
2005-03-30 23:49 ` Ross Johnson
2005-03-31  7:42   ` Dimitar Panayotov
2005-03-31  8:29     ` Ross Johnson [this message]

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=1112257786.19990.180.camel@desk.home \
    --to=rpj@callisto.canberra.edu.au \
    --cc=pthreads-win32@sources.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).