Linux-Development-Sys Digest #894, Volume #6 Sun, 27 Jun 99 00:14:19 EDT
Contents:
Re: Need a.out compiler (Konrad Mieredorff)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: TAO: the ultimate OS (Terry Murphy)
Re: NT kernel guy playing with Linux (Linus Torvalds)
----------------------------------------------------------------------------
From: Konrad Mieredorff <[EMAIL PROTECTED]>
Subject: Re: Need a.out compiler
Date: Sun, 27 Jun 1999 04:00:07 +0200
Aaron Thompson wrote:
>
> exactly. i need the libs.
>
Maybe this question is naive but why don't you compile the libs as
a.out?
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 22:54:07 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Andi Kleen <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Greg Comeau) writes:
>
>> In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nathan Myers)
>writes:
>> >Ralph Glebe <[EMAIL PROTECTED]> wrote:
>> >> Are all the programs in C because: [speculation]
>> >
>> >There are quite a lot of C++ projects on Linux. C projects (still)
>> >outnumber them for several reasons.
>> >
>> >1. C is an easier language to learn to use fully, so you may get
>> > better participation on a C project because you're drawing on
>> > a larger population.
>>
>> This is a nit, and one I believe Nathan will agree with, but IMO,
>> it's not an easier language as much as it's perceived to be an
>> easier language. I mean, sure, C syntax is definitely smaller than
>> C++ syntax and such. But C programming involved more than just that
>> since a C programmer still has to learn general techniques, etc.
>> Also, even specific to C, I find the average C programmer does not
>> know C well. Probably fair to say that they more or less know some
>> subset enough to get by. Anyway, the bottom line is the C is popular
>> and will remain so.
>
>Well, the theory is that:
>
>int f(vector<vector<float> > array)
>
>is easier than
>
>int f(float **array)
>
>to handle for a beginner. The praxis is that what the C++ compiler
>presents you as error message for a slight in template related
>stuff is just horrible, and I wouldn't want to decipher that as
>newbie[1].
>
>-Andi
>
>[1] This is mainly for egcs, I don't know if other C++ compilers
>produce better template-related error messages.
I never said this isn't the case.
Ok, so you found a C++ issue. There's lots more. Lots.
Ok, let's take your case. I've taught intro C and intro C++
many times over the past 10 years. I'm convinced that for every
such undecipherable C++ diagnostic, there's a greater number
of C beginners who don't have a clue what to do with **array.
This is part of my point: **array isn't necessarily easier.
I wouldn't want to decipher that as a newbie either.
Even most people who would claim they are intermediate C programmers
don't get it right.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 22:57:28 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Justin Vallon <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Greg Comeau) writes:
>
>> In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED]
>> (Nathan Myers) writes:
>> >2. It takes substantial extra effort to code C++ libraries that are
>> > binary-compatible from one release to the next, so library version
>> > problems are incrementally harder.
>>
>> This is definitely a roadblock, but I wonder how many people actually
>> realized this when they started out? I would suspect not to many.
>> Luckily Standard C++ is out and at least for now binary compatible issues
>> are known and can be addressed by compiler implementors as they upgrade.
>> Of course, some compilers have done this more than others. :)
>
>Why would binary compatibility between compiler releases be an issue
>for the kernel? Don't you build the entire kernel under one compiler?
>
>Maybe for modules, but you'd extern "C" those, anyway.
>
>Or, are you speaking in general (libnifty.1, libnifty.2)?
Oops, yes, I was speaking in general. But too, if you have something
you were linking into the kernel that you wrote yourself, well,
it would need to be binary compatible, no? (I have not
followed LINUX kernel capabilities, but perhaps it it allows
say a dynamically loadable device driver, though could be an issue??)
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 23:06:42 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l37gc$sib$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nathan Myers)
writes:
>Greg Comeau <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (Nathan Myers) writes:
>>>Ralph Glebe <[EMAIL PROTECTED]> wrote:
>>>> Are all the programs in C because: [speculation]
>>>
>>>There are quite a lot of C++ projects on Linux. C projects (still)
>>>outnumber them for several reasons. ...
>>>
>>>2. It takes substantial extra effort to code C++ libraries that are
>>> binary-compatible from one release to the next, so library version
>>> problems are incrementally harder.
>>
>>Luckily Standard C++ is out and at least for now binary compatible issues
>>are known and can be addressed by compiler implementors as they upgrade.
>>Of course, some compilers have done this more than others. :)
>
>I did not mean releases of the compiler, or releases of the standard
>library, both of which break binary-compatibility but will stabilize,
>eventually.
Ok, I thought that you meant these because....
>I meant releases of other libraries. Any time you change the layout
>of a struct, or (e.g.) add a new virtual function in a base class,
>you risk breaking code that depends on the library. The same is true
>with C libraries, but C lacks some of the language features that create
>a dependency, and people already know about those which do.
>
>It is possible to build C++ libraries that are safe for old program
>binaries to link to, but it's harder. For example, you have to be
>very careful about what inline functions and virtual functions you
>expose in the public interface, and be sure not to change anything
>between releases that those interfaces depend on.
>
>This is a maturity issue. As people become aware of the problems,
>they arrive at the same solution.
....this is "as usual" IMO. Not too trivialize them (they do exist
and do need to be aware of) but I've run into this many many many times
with C. Some of my best "laughs to the bank" (as they say), was as a
C consultant brought in to solve such issues when teams of others couldn't.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 26 Jun 1999 21:53:22 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Anonymous <[EMAIL PROTECTED]>]
> Alternatively, you could have tools that take ambiguous input (still
> in premature development), but I'd rather tell a computer exactly
> what I want than have it guess I want.
Agreed. When I say something is DWIM, it's not a compliment. (:
Years ago (way back when I was a tcsh user) I tried the tcsh
spell-check facility for commands and filenames. It guessed wrong so
often that I quickly dropped it. The amount of customizing necessary
to get it to *actually* Do What I Meant didn't seem to be worth it.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 27 Jun 1999 03:14:17 GMT
In article <7kvd8a$vl$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>More thought? Would you care to elaborate where you feel that pipes
>are under-utilised? Maybe certain applications that were ported from
>other systems could have been re-designed to fit better, but the
>core tools *are* using pipes quite heavily. A prime example is [t,n]roff,
>which strings filters together with gay abandon, and which was the
>motivation offered to management to continue the development of UNIX.
>
>You're making a sweeping statement that is not founded in fact.
>In addition, you fail to offer any rationale for the assertion that
>*if* pipes had been in UNIX1969, the current toolset would have been
>significantly better (at least WRT to using pipes). It's about as
>vacuous as saying that sockets would have been better *had* they been
>in the original design (given the state of the art in networking
>in 1969, they would have been *worse*).
For pipes, they're unidirectional, and you cannot use a program
out of the box for bidriectional communication (you need to
reimplement it with pipes).
Anyways, I was just using those as examples: there are literally
hundreds of annoyances of Unix which are caused by lack of design
and foresight which are fixed up by kludges. I have blathered
about these many times over the years, and don't particularly
want to bore those again who read my messages back then, but you
can just search for me on DEJA.
>The first releases of UNIX were internal products with a small number
>of users. I wasn't there, but I'm quite sure the UNIX people *did* get
>the requirements from their patent department WRT text processing before
>they set out to provide both the OS and the formatter. I'm quite sure
>they *did* unit test both the OS, the formatter, and the macros for
>conformity with the requirements (or the patent department wouldn't
>have used the system), and did whatever tests were required to have
>a satisfactory system.
Do you have any evidence of this? I read Salus's _Quarter Century of
Unix_ and it did not contain much about unit testing and requirements.
I'd actually be quite surprised if this was done at Bell Labs: how much
experience did the organization have with software development at the
time?
>What you fail to see is that once UNIX had become a multi-vendor
>product is was (and is) wholly impossible to impose a strict
>"by-the-book" approach to its evolution.
I understand it, and I understand that this is the root of
many of its problems.
>You're forgetting that
>VMS has essentially died, *because* the development process did not
>allow the system to be adapted to the requirements of the users.
That is SOME historical revision you're doing. VMS lost market share
for two reasons:
(a) Pointy haired managers who believed all of the Unix hype of the
late 80's/early 90's, and converted over. Sun probably has the
highest marketing:quality ratio in the business, and DEC had the
lowest, so this was not a diffcult job for Sun. In the 80's Sun
spread much FUD about DEC.
(b) The VAX was significantly slower than the RISC machines at the
time. The VAXstation 3100 and DECstation 3100 were announced the
same day. Both running Ultrix, the performance was as follows
(in seconds): GNU C (VAXstation: 291, DECstation: 90),
TeX (VAXstation: 449, DECstation: 95), spice (VAXstation: 352,
DECstation: 94) (these numbers are from Patterson & Hennessy)
With Alpha, (b) is no longer a problem. (a) is a still problem but this
time Windows is the enemy, not Unix.
As for VMS being dead, approximately 50% of current customers have
no plans to switch. The remaining 50% plan to switch to Windows.
Of course, the chance that a Windows system will replace a VMS system
is somewhat slim so I expect most of those existing customers to
stick around until Windows gets more enterprise ready (clustering,
especially)
Furthermore, VMS has new customers. For example, the SEC very recently
decided to go with VMS (no small customer there!). There is
VMS presence on the web, especially in e-commerce. E*TRADE is based on
VMS, and I believe many other of the on-line trading companies are as well.
As for VMS not being adaptable to users requirements, that is pure
rubbish. Where do you come up with these statements? Here is what
VMS systems are used in right now, every day: they control 90%
of silicon wafer fabs, they run the entrerprise systems for 18 of
the top 20 U.S. banks, they run over 100 stock exchanges worldwide,
including 17 of the largest 20, and 60% of electronics funds transfer
are done with a VMS system.
But I will save my favorite VMS application for last: development
and manufacture of the Alpha microprocessor. On his desk, every
circuit designer on the project has a VMS workstation. All of the
servers which deliver mail among team members, hold users file systems,
and run batch job simulations are running VMS. Furthermore,
the fabs which manufacture the silicon is also running VMS. So you
simultaneously have one single operating system which is used for
workstation, server, and industrial control. And don't you dare say
Alpha suffers from being designed/manufactured on VMS: it is the
fastest microprocessor in the world.
So I ask, what about VMS do you insist is not adaptable? I challenge
you to name one single solitary Unix flavor which is simultaneously
used as in workstations, servers, e-commerce, stock exchanges, banks,
and industrial control (Solaris probably comes the closest, but it
has all sorts of different versions, and third party patches to make
it more secure, etc., so it's not really one system).
>But it was done nonetheless. Separate license or not, VMS was modified
>to support POSIX, and this was not foreseen in the original design,
>which is what we're talking about.
No, VMS has not modified to support POSIX. It was simply a a library,
which was not included in the base system, and had to be installed to
get the functionality. What about this is modification to VMS?
>Again, dear Terry, give me a break. MS engineering has been non-existing,
>because they've largely bought products and adapted them (more or less
>successfully). Their 'C' compiler started out as Lattice 'C'. I forget
>whom they bought Powerpoint from. Excel is also an outside acquisition.
So I guess in your world, Sun invented Unix and did not buy it
from AT&T. So did SGI. And IBM. And HP. And DEC. And I suppose Torvalds
never saw anything called Unix in his life, but thought up all of this
stuff by himself. They just happened to stumble upon this by
engineering, and the similarities among each other are purely
coincidental. Please.
As for Excel, that started as a DOS based product, which was probably
written in assembly language and ran in something like 128k. Surely
you don't believe it has anything at all in common with Excel 2000 (or
whatever the latest version is) besides the name?
>They scrambled like mad to get compression into MS-DOS when Stacker
>turned out to be successful. They scrambled like mad to get TCP/IP into
>windows when the Internet turned out to be a success.
Scrambling like mad is what you do in this business.
-- Terry
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Subject: Re: NT kernel guy playing with Linux
Date: 27 Jun 1999 03:25:59 GMT
In article <7l3oan$mrj$[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
>I say this in the hope of sparing others the confusion I had about what
>a spinlock is. (It looked a lot like what CS calls a semaphore, so why
>don't they just call it a semaphore, and what's this semaphore_t...?)
If your CS courses didn't tell you the difference between a semaphore
and a spinlock, your CS courses were bad (or just didn't cover much
about concurrency, which is fairly common).
Blame your professors, don't blame the Linux kernel code.
>A spinlock is a semaphore used for very short critical sections; while
>waiting for a spinlock to be released, the kernel sits on the CPU and
>does nothing.
A spinlock is a mutual exclusion mechanism, not a semaphore (a semaphore
is a very specific _kind_ of mutual exclusion).
But yes, you're right in that it's (by design) a busy-waiting one.
That's why they are called "spinlocks" - they "spin" waiting for the
lock to go away.
> A `semaphore_t' is a longer-term semaphore which has the
>advantage that the kernel puts the needy process to sleep and goes and
>does something else rather than busy-waiting.
A semaphore also has the ability to have more than one process enter the
critical region. Basically semaphores were (as far as I know) first
proposed by Dijkstra, and they explicitly imply a "sleep"/"wakeup"
behaviour, ie they are _not_ spinlocks. They originally had operations
called "P()" and "V()", but nobody ever remembers whether P() was down()
or up(), so nobody uses those names any more. Dijkstra was probably a
bit heavy on drugs or something (I think the official explanation is
that P and V are the first letters in some Dutch words, but I personally
find the drug overdose story much more believable).
Also, unlike basic spinlocks, a semaphore has a "count" value: each
process that does a down() operation decrements the count if positive,
until the count would go negative. Only then do they sleep. The
original intent of this was to allow multiple entries to the region
protected by the semaphore: by initializing the count to 4, you allow
four down() operations and only the fifth one will block.
However, almost all practical use of semaphores is a special case where
the counter is initialized to 1, and where they are used as simple
mutual exclusion with only one user allowed in the critical region.
Such a semaphore is often called a "mutex" semaphore for MUTual
EXclusion.
I've never really seen anybody use the more complex case of semaphores,
although I do know of cases where it can be useful. For example, one use
of a more complex semaphore is as a "throttle", where you do something
like this:
/* Maximum concurrent users */
#define MAX_CONCURRENT_USERS 20
struct semaphore sem;
init_sema(&sem, MAX_CONCURRENT_USERS);
and then each user does a down() on the semaphore before starting an
operation. It won't block until you have 20 users - you've not created
a mutual exclusion, but you HAVE created a throttling mechanism. See?
Potentially useful, as I said, but the common case (and the only case
currently in use in the Linux kernel - even though the implementation
definitely can handle the general case) is certainly the mutex one.
>However, you need to grab a spinlock for the purpose of grabbing a
>semaphore_t, so for short critical sections a spinlock (even with the
>potential of busy-waiting) is more efficient.
Only in bad implementations or on bad hardware.
All reasonably modern CPU's can do a semaphore without having grabbed a
spinlock. Often a spinlock is needed for the _contention_ case, but if
done right that is very rare. The contention case for a semaphore is
usually the very expensive one, because that's when you have to
re-schedule etc.
So basically spinlocks are much simpler, and faster under short-lived
contention, so that's why they tend to be used. Also, semaphores cannot
be used by interrupt handlers, as Linux doesn't allow interrupt handlers
to sleep, so anything that protects interrupts needs to be a spinlock.
In addition to semaphores, there are other mutual exclusion notions, the
most popular being a "read-write" lock - something that requires
exclusive access for writers, but allows any number of readers at a
time. Linux has the spinning version of this, but not the blocking one.
We'll probably add a blocking version some day, as it's often very
useful, but it hasn't been a major issue yet.
For example, the per-VM memory management semaphore could very usefully
be a blocking read-write lock, but without heavy thread contention a
mutex semaphore is basically equivalent.
> Since the usual practice
>is to make your critical sections as short as possible, the result is
>that the kernel uses a lot more spinlocks than semaphore_t's.
True. Semaphores are really only useful around anything that does IO,
for example. When the potential contention period is multiple
milliseconds as opposed to nano- or microseconds, blocking operations
(ie operations that cause a re-schedule on contention) are the right way
to go.
Note that some people believe in a mix-and-match approach, where you
have a spinlock that gets upgraded to a semaphore if it waits too long.
Personally, I think that only makes sense if (a) you're in user space
and don't know what the scheduling rules are or (b) your locking is so
badly designed that you have tons of short-lived contention on your
semaphores, so you want to try the light approach first.
Linus
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
