public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@ise.canberra.edu.au>
To: pthreads-win32@sources.redhat.com
Subject: Re: Borland C++Builder support
Date: Fri, 06 Aug 2004 16:55:00 -0000	[thread overview]
Message-ID: <4113B7D2.7090807@ise.canberra.edu.au> (raw)
In-Reply-To: <41138855.1010605@ecosm.com>

Will Bryant wrote:

> Gianluca wrote:
>
>> I have built the library with the Will Bryant's bmakefile.
>> I've received a bunch of warnings but it was OK.
>> I put the PthreadBC.dll on Windows directory, I included
>> PthreadBC.lib in my .bpr project, I compiled and linked the program 
>> below.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <pthread.h>
>>
>> void*  function( void*  arg )
>> {
>>   printf( "This is thread %d\n", pthread_self() );
>>   return( 0 );
>> }
>>
>> int main( void )
>> {
>>   pthread_attr_t attr;
>>
>>   pthread_attr_init( &attr );
>>   pthread_attr_setdetachstate(
>>      &attr, PTHREAD_CREATE_DETACHED );
>>   pthread_create( NULL, &attr, &function, NULL );
>>  
>>
> In general (ie. not for pthreads-win32 specifically), you need to 
> declare a pthread_id_t and pass it's address as the first argument to 
> pthread_create.  Try making that change first.
>
There are pthreads implementations that allow a NULL thread 
parameter (Solaris - see below) and the question of a NULL 
value has been asked before on this list. My copy of the 
SUSV3 standard doesn't say that NULL can't be passed and 
doesn't require an error be returned. It appears to be left 
to the implementation.

In pthreads-win32, a memory protection fault is raised if 
NULL is passed, but it also starts the thread before the 
fault is raised, which is probably a bug.

I've run the following test on machines that I have access to:

#include <stdio.h>
#include <pthread.h>
 


void *
thr(void * arg)
{
  printf("Inside thread\n");

  /* Mandatory if we're going to be well behaved. */
  pthread_detach(pthread_self());
}
 


int
main()
{
  pthread_t t;
  int result = 0;

  result == pthread_create(NULL, NULL, thr, NULL);
  sleep(2);

  return result;
}


Linux (Redhat 9) segfaults without running the thread.
Solaris 7 runs the thread and exits with no error or fault.

Pthreads-win32 could probably emulate Solaris with a one 
line change. The question is:- which behaviour is preferrable?

Ross


  reply	other threads:[~2004-08-06 16:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-03 10:04 Gianluca
2004-08-06 13:31 ` Will Bryant
2004-08-06 16:55   ` Ross Johnson [this message]
2004-08-07  2:52     ` Will Bryant
2004-08-07  2:50   ` Will Bryant
  -- strict thread matches above, loose matches on Subject: below --
2004-06-14  4:30 Will Bryant

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=4113B7D2.7090807@ise.canberra.edu.au \
    --to=rpj@ise.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).