Re: Patch for sC++ to GNU C++.

[Ken Raeburn <raeburn at cygnus dot com>]

Here are some comments I had for Jason when he asked my opinion of the
patches in August.  (I've spent a bit of time working on a Concurrent
C front end, and when MRS was still at Cygnus, pestering him about
thread-safety issues.)  We haven't discussed it since.

Most of my comments are about the generic extension issues, a few
about sC++ specifically.  Some of the issues have already been brought
up in this discussion.  I didn't take as much time as I could've to
investigate the details of the sC++ implementation, and didn't talk to
Jan about it at all, so some of my concerns may be unfounded.

Ken

 To: Jason Merrill <jason@cygnus.com>
 Subject: Re: [Jan Madsen <Jan.Madsen@epfl.ch>] Patch for the sC++ extension.
 From: Ken Raeburn <raeburn@cygnus.com>
 Date: 24 Aug 1998 16:28:45 -0400

 > Thoughts?

 Several...

 First: It'd be great to have some sort of extension for multithreaded
 programs available.  Yes, the Posix library spec is okay, but (1) it's
 only one thread API of several we have to deal with, and (2) it deals
 with low-level issues, and stuff like message-passing has to be built
 on top of it all the time, locking has to be explicitly done, etc.
 Having a language extension puts the API issues under the covers, and
 (generally) lets you specify in one places that all accesses to an
 object should be done with locks, and often lets you say "pass this
 message with these six values, and get a value back".

 I'd rather see something available for C as well, and if I get really
 psyched about it I'll work on Concurrent C/C++ again (looks like my
 previous work is lost to a disk crash and bad backup tapes, but hey,
 parts of it really needed a rewrite anyways).  In fact, some (not all)
 of the sC++ extensions look remarkably like Concurrent C/C++
 extensions, with slightly different syntax, and without support for C.
 (Of course, both the sC++ and Concurrent C extensions also bear some
 resemblance to Ada constructs.)

 Second: I think at some point we should address the general issue of
 extensions to C and C++.  Maybe there isn't anything "general" that we
 can do, but I think we should investigate, and as far as I know no one
 has.  There are several issues to look into, I'm sure; only a few come
 to me off the top of my head.

 * Grammar: The "@" additions to the C++ grammar might conflict with an
   Objective C++ front end.  Some of the new keywords will definitely
   conflict with Concurrent C++.  The grammar gets new hooks all over
   the place for this extension, I think even more so than for
   Concurrent C++.  The new rules in the grammar are active even if the
   extensions are not enabled.

 * How to hook in: Should we add command-line options to enable
   extensions, as they've done, or create new programs like cc1obj that
   have the extensions, and leave them out of the "ordinary" back end?
   Does it matter if we're consistent?

 * Intrusiveness: Should we put "if objc" and "if (flag_synccxx)" hooks
   in all over the place, specific to each extension, or can we find a
   way to add generic hooks in all these places (including the grammar
   and lexer themselves?) that an extension "package" (or more than
   one) can make use of?

 * Combining multiple extensions: Can we produce some mechanism by
   which an "Objective sC++" compiler would just sort of fall out
   naturally?  Grammar and keyword conflicts would have to be handled
   somehow, so possibly the answer is no.  Maybe the answer is to add
   all the hooks and grammar extensions and resolve conflicts up front,
   then selectively enable those additions at run time.

 This could get into a big can of worms, and the easy way out is to
 just deal with it for each such language extension that comes along.
 That works, but has little chance of making it easier to write new
 language extensions.  Maybe that's not important; I don't expect all
 that many to come along, but some do.  For example, database
 extensions, other concurrent-execution models.

 Third: This appears to do synchronous, cooperative multithreading,
 rather than async posix-style (and gthr.h-style) multithreading.  This
 makes it of relatively limited use, in my opinion, but I'm sure it has
 its place.  You have to use their thread mechanism, and their new
 header file in every source file, at least if you use their
 extensions.  (The compiler could be hacked to always read the
 structures and function declarations from the header file without
 explicitly including it from the source file, or hard-code the info
 within the compiler.)  The header file is a little sloppy about
 namespace invasion, and includes some system header files.

 They're assuming that sigsetjmp/siglongjmp are adequate for switching
 threads.  I'm not sure that's all that safe.

 It looks like the library support is only ported to Alpha, Sparc, and
 SGI systems, in the tar file I fetched.  Actually, there's a Linux one
 as well, but the fact that it's a separate distribution doesn't look
 good.  Maybe that's what the "generic" configuration part refers to,
 but how generic can it be if Alpha, Sparc, and SGI each need their own
 replacement definitions?

 Fourth: Minor stuff...  Changing some of the names/spellings to
 English might make it easier on many of the users.  They use the name
 "sC++" in some places and "SyncC++" (the older name of the project, I
 think) in others, and that probably should be made consistent.  Also,
 I've got some minor concerns about just how the hooks into the grammar
 are written (e.g., are they changing the semantics more than they
 should), but I'm sure you'd review that more carefully than I have.
 And I doubt they've checked for proper interaction with templates.