From: Will Bryant <will.bryant@ecosm.com>
To: pthreads-win32@sources.redhat.com
Subject: Re: Borland C++Builder support
Date: Sat, 07 Aug 2004 02:52:00 -0000 [thread overview]
Message-ID: <41144407.4000702@ecosm.com> (raw)
In-Reply-To: <4113B7D2.7090807@ise.canberra.edu.au>
Ross Johnson wrote:
> 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.
My Linux man page says "On success, the identifier of the newly created
thread is stored in the location pointed by the _thread_ argument, and a
0 is returned.", and my Solaris man page says "Upon successful
completion, pthread_create() stores the ID of the created thread in the
location referenced by _thread_.", so strictly speaking since neither
says "if _thread_ is non-NULL" one should _expect_ that it would
segfault, though only a true pedant would claim that it's a bug if it
doesn't.
> 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 agree, it should do one or the other.
> Pthreads-win32 could probably emulate Solaris with a one line change.
> The question is:- which behaviour is preferrable?
Good question. Presumably anyone who's using pthreads-win32 is using it
to acheive cross-platform portability. I was initially going to put in
my vote for cleanly handling this as an error condition, on the basis
that that way people can expect their pthreads-win32 programs to run on
Linux. But, having thought about it a bit more, I think it's more
likely that people using pthreads-win32 will be porting solaris
applications to win32 than writing win32 apps with pthreads and then
porting them to Linux.
So my vote is to go with the Solaris behaviour and accept NULL arguments.
But I would like it to be documented somewhere that this behaviour is
not required. Either behaviour seems acceptable to me, just not the
current half-works, half-doesn't behaviour.
next prev parent reply other threads:[~2004-08-07 2:52 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
2004-08-07 2:52 ` Will Bryant [this message]
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=41144407.4000702@ecosm.com \
--to=will.bryant@ecosm.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).