public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@callisto.canberra.edu.au>
To: Meno Abels <meno.abels@adviser.com>
Cc: pthreads-win32@sources.redhat.com
Subject: Re: pthread library static linking
Date: Fri, 23 Apr 2004 07:34:00 -0000	[thread overview]
Message-ID: <4088C746.9090703@callisto.canberra.edu.au> (raw)
In-Reply-To: <4088AD69.2010508@adviser.com>

One reason, and possibly the only reason, is that pthreads-win32 allows 
Win32 threads (those not started via pthread_create) to call pthreads 
routines. But to do this usually generates an on-the-fly pthread handle 
for the Win32 thread so that it can be managed. Effectively, any Win32 
thread that calls a pthreads routine becomes a POSIX (DETACHED) thread 
from the library's point of view. The hooks in dllMain enable cleanup of 
these 'implicit' pthread handles because the library has no other way of 
knowing when they exit.

The routines that dllMain calls were split out and are exported so that 
they could be called in statically linked applications. See dllMain.c 
and README.NONPORTABLE.

Now, I could be wrong, but if Win32 threads never call pthreads routines 
then your statically linked application may not need to explicitly call 
these dllMain hooks. Threads created via pthread_create should be 
getting cleaned up at the end of ptw32_threadStart(). You could try it, 
but check for memory leaks.

Ross

Meno Abels wrote:

> hello,
>
> i'am new here so one question is allowed-:)
> I want to use pthread-win32 not as a dll. I want
> to link the pthread-win32 functionality static
> to my application just to make distribution of that
> application easier.
> So that is quite easy to get, but there are the DllMain.
> In DllMain you use the DLL_THREAD_ATTACH/DLL_THREAD_DETACH.
> These prevents to use your lib static linked. Not technical
> but functional. The DLL_PROCESS_ATTACH/DETACH is simple to
> simulate infact I will call it on startup and end of my
> application direct. The thread stuff is more complex i have to
> change the thread create and thread exit code of your library.
> My basic question is why you choose this solution with
> DllMain. The pthread library is a wrapper around the
> windows functions so it would be obvious to add the needed
> initialisation for the create and exit directly.
> Why is this done with DllMain?
>
> Thanks in advance
>
> meno
>

      reply	other threads:[~2004-04-23  7:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-23  5:45 Meno Abels
2004-04-23  7:34 ` 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=4088C746.9090703@callisto.canberra.edu.au \
    --to=rpj@callisto.canberra.edu.au \
    --cc=meno.abels@adviser.com \
    --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).