In article <CG6L5w.4GB@biles.com> daniels@biles.com (Brad Daniels) writes:
>
>Actually, that brings up an interesting side-issue:  Is an implementation
>required to allow overloading on a function which uses "C" calling
>conventions under one signature?...

Yes and no.

The following is allowed:

  extern "C" void foobar (int);
  extern void foobar (int, int);

The following is NOT allowed:

  extern "C" void foobar (int);
  extern "C" void foobar (int, int);

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

Ronald F. Guilmette (rfg@netcom.com) wrote:
: But if *I* had *my* druthers, I'd druther that the ANSI C standard had
: mandated that all library function which *could* be reentrant *must* be
: reentrant.  (And I hope that this is one area in which X3J16 will have
: more intestinal fortutude than did X3J11.)
hmmmm.....
I could make strtok (and many (all??) others like it) reentrant by addings
args.  In C++ it could be an overloaded func so that you would get the
reentrant function when you gave the extra arg (buffer).  Maybe a
completely reentrantable version of the standard c library should be
designed???
: Up with reentrancy!
On the other hand one could argue that threads are the solution to OS'
that don't have fast enough context switches (I just argued against this
point in comp.os.* the other day, but then what the hell) so threads are
really bastard solutions to todays problems.
: -- Ronald F. Guilmette, Sunnyvale, California -------------------------------
: ------ domain address: rfg@netcom.com ---------------------------------------
 Michael Hunter
 bagpiper@netcom.com

Pete Becker (pete@borland.com) wrote:
: In article <rfgCFsrF7.4CF@netcom.com>,
: Ronald F. Guilmette <rfg@netcom.com> wrote:
: >
: >Ok.  So let me ask you (and your collegues) a question... Is it even
: >*possible* to implement C++ exceptions in a "thread safe" manner?
: >

:  Yes, it is possible.
:  -- Pete

 Can you follow that up with more data (example of imp, etc.) ??

  Michael Hunter
  bagpiper@netcom.com

In article <bagpiperCG5oFA.Dt6@netcom.com>,
Michael Hunter <bagpiper@netcom.com> wrote:
>Ronald F. Guilmette (rfg@netcom.com) wrote:
>: But if *I* had *my* druthers, I'd druther that the ANSI C standard had
>: mandated that all library function which *could* be reentrant *must* be
>: reentrant.  (And I hope that this is one area in which X3J16 will have
>: more intestinal fortutude than did X3J11.)
>hmmmm.....
>I could make strtok (and many (all??) others like it) reentrant by addings
>args.  In C++ it could be an overloaded func so that you would get the
>reentrant function when you gave the extra arg (buffer).  Maybe a
>completely reentrantable version of the standard c library should be
>designed???

The POSIX realtime extensions (pthreads) already mandate reentrant versions
of the C RTL functions.  The functions have the same names as the non-reentrant
versions, but with "_r" appended.  In C++, it would be simple to implement
overloaded versions with the same name but the re-entrant calling sequence.

Actually, that brings up an interesting side-issue:  Is an implementation
required to allow overloading on a function which uses "C" calling
conventions under one signature?  It works on DEC C++, g++ 2.4.5, and
HP C++, but I don't see where it's required.  I've been known to miss
things in the ARM before though.

...
>On the other hand one could argue that threads are the solution to OS'
>that don't have fast enough context switches (I just argued against this
>point in comp.os.* the other day, but then what the hell) so threads are
>really bastard solutions to todays problems.

Shared address space has actual functional advantages independent of the
performance advantage of multiple threads of execution in a single context.

- Brad
----------------------------------------------------------------------
+ Brad Daniels   | "Let others praise ancient times;  +
+ Biles and Associates  |  I am glad I was born in these."   +
+ These are my views, not B&A's |   - Ovid(43 B.C - 17 A.D)    +
----------------------------------------------------------------------

In article <bagpiperCG5osp.EH2@netcom.com>,
Michael Hunter <bagpiper@netcom.com> wrote:
>Pete Becker (pete@borland.com) wrote:
>: In article <rfgCFsrF7.4CF@netcom.com>,
>: Ronald F. Guilmette <rfg@netcom.com> wrote:
>: >
>: >Ok.  So let me ask you (and your collegues) a question... Is it even
>: >*possible* to implement C++ exceptions in a "thread safe" manner?
>: >
>
>:  Yes, it is possible.
>:  -- Pete
>
> Can you follow that up with more data (example of imp, etc.) ??
>

 Borland C++ 4.0. Coming soon to a software store near you...
 -- Pete

In article <1993Nov9.040314.19115@borland.com> pete@borland.com (Pete Becker) writes:
>In article <bagpiperCG5osp.EH2@netcom.com>,
>Michael Hunter <bagpiper@netcom.com> wrote:
>>Pete Becker (pete@borland.com) wrote:
>>: In article <rfgCFsrF7.4CF@netcom.com>,
>>: Ronald F. Guilmette <rfg@netcom.com> wrote:
>>: >
>>: >Ok.  So let me ask you (and your collegues) a question... Is it even
>>: >*possible* to implement C++ exceptions in a "thread safe" manner?
>>: >
>>
>>:  Yes, it is possible.
>>:  -- Pete
>>
>> Can you follow that up with more data (example of imp, etc.) ??
>>
>
> Borland C++ 4.0. Coming soon to a software store near you...
> -- Pete

I was *seriously* concerned that there might be something hiding in the
specifications regarding C++ exception handling that might make it im-
possible to implement in a reentrant manner.  Thus, am am indeed pleased
to have been reassured that this is NOT the case (by the contributors
from both HP and Borland).  I am even more pleased to know that (rather
than taking anyone's word for it) I shall soon be able to actually view
a working proof with my own eyes!  (That, it seems to me, ought to remove
all doubts which *anyone* might have been harboring along these lines.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <bagpiperCG5oFA.Dt6@netcom.com> bagpiper@netcom.com (Michael Hunter) writes:

   Ronald F. Guilmette (rfg@netcom.com) wrote:
   : But if *I* had *my* druthers, I'd druther that the ANSI C standard had
   : mandated that all library function which *could* be reentrant *must* be
   : reentrant.  (And I hope that this is one area in which X3J16 will have
   : more intestinal fortutude than did X3J11.)
   hmmmm.....
   I could make strtok (and many (all??) others like it) reentrant by addings
   args.  In C++ it could be an overloaded func so that you would get the
   reentrant function when you gave the extra arg (buffer).  Maybe a
   completely reentrantable version of the standard c library should be
   designed???

The HP implementation of DCE comes with a re-entrant libc (libc_r)
that supplies re-entrant version of most of the libc stuff. Some have
changed interfaces (eg. with user supplied buffers where appropriate).

   : Up with reentrancy!
   On the other hand one could argue that threads are the solution to OS'
   that don't have fast enough context switches (I just argued against this
   point in comp.os.* the other day, but then what the hell) so threads are
   really bastard solutions to todays problems.

Threads are more than just a fast context switch, there is less
context switched. The major thing that threads supply for me is the
sharing of the heap and global data (yes and it is a pain sometimes
too!) Passing an object between two unix processes is a pain, between
two threads is easy, a pointer! (yes, I know there is shared memory
and that is a right royal pain in the a..)

--
brian wallis...   <brw@ephor.tusc.oz.au>
TUSC Computer Systems Pty.Ltd Melbourne Australia.
Phone: +61 3 840 2222  Fax: +61 3 840 2277

In article <rfgCFsrF7.4CF@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <CFn29I.DHJ@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:
>>... The HP compiler folks are well aware of the problems
>>with exceptions and concurrency and are working on the them.
>
>Ok.  So let me ask you (and your collegues) a question... Is it even
>*possible* to implement C++ exceptions in a "thread safe" manner?

I'm pretty certain that it's possible.

--steve

Steve Vinoski  vinoski@apollo.hp.com    (508)436-5904
Distributed Object Computing Program    fax: (508)436-5122
Hewlett-Packard, Chelmsford, MA 01824

In article <rfgCFsqxx.3p3@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>Up with reentrancy!
>

 You'd have to get rid of Unix first.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <rfgCFsrF7.4CF@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>Ok.  So let me ask you (and your collegues) a question... Is it even
>*possible* to implement C++ exceptions in a "thread safe" manner?
>
>If not, maybe the X3J16 C++ standardization committee ought to consider
>totally redesigning C++ exceptions so that they *can* be implemented in
>a thread-safe manner.

 Threads are outside the scope of the memory/execution
model of C++. Maybe the next version of the Standard will cope with
them. Not building support for threads/tasks/etc into the language
was a deliberate decision by Stroustrup right at the inception
of C++: the first class library for which was the AT&T tasking
library, I believe.

 So its a bit tricky to write words about threads
in a document which cant acknowledge their existence.
Its up to vendors to do the work on this one.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CFswq9.2xu@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <rfgCFsrF7.4CF@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>Ok.  So let me ask you (and your collegues) a question... Is it even
>>*possible* to implement C++ exceptions in a "thread safe" manner?
>>
>>If not, maybe the X3J16 C++ standardization committee ought to consider
>>totally redesigning C++ exceptions so that they *can* be implemented in
>>a thread-safe manner.
>
> Threads are outside the scope of the memory/execution
>model of C++. Maybe the next version of the Standard will cope with
>them. Not building support for threads/tasks/etc into the language
>was a deliberate decision by Stroustrup right at the inception
>of C++: the first class library for which was the AT&T tasking
>library, I believe.
>
> So its a bit tricky to write words about threads
>in a document which cant acknowledge their existence.
>Its up to vendors to do the work on this one.

John, I think you've misread me (again).

I agree that "threads" per se are outside of the scope of the C++ standard,
but "reentrancy" certainly is *not* outside of the scope of the standard.
In fact I hope and trust and believe that the final C++ standard *will*
say a good deal about reentrancy (just as the C standard already does).

Anyway, what you seem to have missed is that *if* the standard says some-
thing like "implementations must generate reentrant code" that is pretty
much tantamount to having said "implementations must generate thread-safe
code".  There isn't really a lot of difference between these two terms.

Now, getting back to the point, I would definitely *like* to see the final
C++ standard say "implementations must generate reentrant code".  However
I am now wondering (out loud) if it will be possible for the standard to
contain such a rule *and* to contain all that stuff relating to C++
exceptions.  Maybe we just can't have both.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCFsrF7.4CF@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>
>Ok.  So let me ask you (and your collegues) a question... Is it even
>*possible* to implement C++ exceptions in a "thread safe" manner?
>

 Yes, it is possible.
 -- Pete

In article <CFn29I.DHJ@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:

   The HP exceptions implementation currently uses global variables in
   its runtime, so it is not thread-safe.  I suppose it might be possible
   to maintain a per-application mutex that is grabbed before a throw
   occurs and released after the catch, but even that solution will fail
   if the application uses a binary library product that also throws
   exceptions (if you've got library source, then of course it too can be
   fixed to use the mutex).  All in all, such a workaround seems highly
   error-prone.  The HP compiler folks are well aware of the problems
   with exceptions and concurrency and are working on the them.

Being the originator of this conversation (but not the poster, that
was a colleague), I thought an update is in order.

comp.std.c++ is probably not the right place for this so I'll keep it
brief.

We have a basically working scheme that we can probably survive with
until HP sort out the compiler.

It involves saving the exception state (4 global variables) before
each thread swap in some thread specific "global" storage and
restoring it after restarting a thread. The details are very DCE
thread specific and involve running a thread scheduler that will not
pre-empt a thread (FIFO), making all threads the same priority and
disallowing a number of things in destructors and during exception
processing. These things we can live with until the compiler supports
it properly.

I wonder when it will ?? :-) (anyone know and willing to say?)

We don't need the mutex around the exception handling and we do have
the source to all used C++ libraries.

   For single-threaded applications, I think the only way signals could
   screw up the HP exceptions implementation is if a signal handler did a
   throw() while a previous throw() was still in progress.

And if you do that, you deserve what you get!

--
brian wallis...   <brw@ephor.tusc.oz.au>
TUSC Computer Systems Pty.Ltd Melbourne Australia.
Phone: +61 3 840 2222  Fax: +61 3 840 2277

In article <CFn29I.DHJ@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:
>In article <rfgCFL3wL.7Gt@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>P.S. While it would be nice if both C and C++ compilers would avoid code
>>generation patters which unduly impare reentrancy, it should be kept in
>>mind that even in ANSI/ISO C, library functions are not guarranteed to
>>be reentrant.  A requirement for LIBRARY reentrancy would (if it existed)
>>create a severe burden on C/C++ implementors, and is probably not warranted.
>
>Given the fact that threads and concurrency are becoming more and more
>common in software systems, I would hope that the eventual C++
>standard does nothing to prohibit a conforming implementation from
>providing a completely reentrant standard library.  Functions that are
>inherently non-reentrant, such as ANSI/ISO C strtok(), are simply a
>botch that should not be allowed.
>
>Furthermore, I'm not sure a requirement for library reentrancy would
>"create a severe burden on C/C++ implementors" because I think any C++
>compiler and runtime combination that is worth anything is soon going
>to have to support reentrancy to remain competitive.

Well OK Steve.  You painted me into a corner.  Now I'll have to tell you
how I *really* feel about this.

In truth, my earlier comments were less a reflection of my own feelings
on the matter than they were a reflection of the (apparent) collective
wisdom of the X3J11 (ANSI C) standardization committee.  Obviously, they
explicitly put in verbage saying that the C library didn't have to be
reentrant.  (And as you noted Steve, in some cases, for some functions,
it may just be plain IMPOSSIBLE for them to be implemented in a reentrant
fashion.)  So my interpretation is that X3J11 (at least) felt that a
requiment for the library to be reentrant would "create a severe burden
on implementors" (as I put it).

But if *I* had *my* druthers, I'd druther that the ANSI C standard had
mandated that all library function which *could* be reentrant *must* be
reentrant.  (And I hope that this is one area in which X3J16 will have
more intestinal fortutude than did X3J11.)

Up with reentrancy!

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CFn29I.DHJ@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:
>In article <rfgCFL3wL.7Gt@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>P.P.S.  Given the above quoted disclaimer that the HP implementation of
>>exceptions is NOT reentrant with respect to threads, I am inclined to
>>wonder if it is likewise non-reentrant with respect to mere signals.
>>Would anyone familiar with the HP exception implementation care to
>>comment on this?
>...
>For single-threaded applications, I think the only way signals could
>screw up the HP exceptions implementation is if a signal handler did a
>throw() while a previous throw() was still in progress.

I think you answered my question.  The HP implementation of exceptions
*can* screw up... even in cases where the user is *not* using threads
in any way.

Given that you folks have been good enough to document the problems (bugs?)
which can arise when your implementation of exceptions is used in con-
junction with threads, it would seem like you ought also to document
the problem (bugs?) which can arise when a single program uses both
exceptions and signals.

(The final ANSI/ISO C++ standard may remain entirely silent on the subject
of threads, but I doubt that it will condone bizzare behavior in cases
where "standard" features, such as exceptions and signals, interact.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CFn29I.DHJ@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:
>
>The HP exceptions implementation currently uses global variables in
>its runtime, so it is not thread-safe...

>... The HP compiler folks are well aware of the problems
>with exceptions and concurrency and are working on the them.

Ok.  So let me ask you (and your collegues) a question... Is it even
*possible* to implement C++ exceptions in a "thread safe" manner?

If not, maybe the X3J16 C++ standardization committee ought to consider
totally redesigning C++ exceptions so that they *can* be implemented in
a thread-safe manner.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CFpBoE.Jvr@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <rfgCFL3wL.7Gt@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>I note with dismay that no such restrictions currently apply to C++ com-
>>pilers.  I hope that this is a mere oversight which will be corrected in
>>due course by the X3J16 C++ standardization committee.
>>
>>I see no reason why C++ exceptions should not work correctly, even in cases
>>involving signals and/or cases involving concurrency.  If you agree with
>>this view, you would be well advised to inform your local X3J16 representa-
>>tive of your feelings in this matter so as to further the chances that X3J16
>>will in fact stipulate (in the C++ standard) that conformant C++ compilers
>>must be able to generate reentrant object code.
>
> Most compilers generate reentrant code, I would have thought.

John, you have missed the point entirely.  I wish to be able to write
*portable* code which *relies* on the assumption that the compiler does
indeed generate reentrant code.  But the current X3J16 draft doesn't
contain any language which even *encourages* implementors to provide
compilers which generate reentrant code (let alone wording *requiring*
them to do so).

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------