Re: [boost] Re: Re: Re: Platform Neutrality-withoutreinterpret_cast<>andifdef

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-08-07 04:14:28

At Tuesday 2002/08/06 07:36, you wrote:
>----- Original Message -----
>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Tuesday, August 06, 2002 4:08 AM
>Subject: Re: [boost] Re: Re: Re: Platform
>Neutrality-withoutreinterpret_cast<>andifdef
>
>
> > Geez, I hate to have to chime in on Eric's side (since I disagree with
>some
> > of what he says), but it _should_ be the "stated" or "posted" will of the
> > community.  I found the arguments ("they're not safe") for deleting
> > semaphore so specious that I gave up on attempting any further criticism.
>
>You shouldn't have.  Semaphores weren't relegated to absolute non-inclusion.
>They were removed as being dangerous enough to warrant serious research and
>design before consideration of actual inclusion.

we disagree here.  I worked for almost 20 years building embedded systems 
on which people's lives depended with "raw semaphore" as the underlying 
synchronization method.  As I commented the last time this came up, we had 
the advantage of not being hindered by a "language" which in it's design 
gave NO thought to multi-tasking, rather we were designing both the 
instructions sets and the computers on which the systems would run.

> > Ben Franklin said (in respect to human interaction)"They that can give up
> > essential liberty to obtain a little temporary safety deserve neither
> > liberty nor safety."
> > I believe the same applies here.  Refusing to implement some method of
> > being able to pass an exception (ok, maybe not ALL exceptions, I
>personally
> > find the concept of "throw 7;" to be an abomination of the body of C++)
> > across thread boundaries because it's not "safe' disappointing.
>
>Depends on what you mean by "pass".  Asynchronous exceptions are so unsafe
>that they are basically not usable.

we certainly agree here.  Again we're hindered by not having appropriate 
things in C++ (this isn't to denigrate C++, it's simply _outside_ the 
bounds of what it was designed to do).  I will point out that Asynch 
exceptions are no more unsafe than interrupts in a system, but at least 
there are instructions (on the machine, not C++) to deal with those.

>  A polling form of exception passing is
>usable for select cases.

is IS unusable for select cases, and "simply marvelous" for others.

>   For instance, that's precisely how thread
>cancellation will be implemented.  The boost::threads design does not
>exclude the ability to do this today.   I'm leaning towards leaving this
>subject at that because:
>
>1) It's difficult to use this in a manner that's safe and correct and will
>be abused and misused frequently if it's added to the provided interface.
>
>2) It's rarely useful.
>
>3) Implementing it yourself is trivial, and can often be optimized for your
>specific needs.
>
> > axiom1: there is no such thing as "absolute safety".
>
>Of course not.
>
> > axiom2: attempting to reach "absolute safety" is like searching for the
> > "end of the rainbow"
>
>Not really.  Searching for the end of the rainbow is simply wasted effort.
>Reaching for "absolute safety", on the other hand, can help a design to
>actually be safer, even though "absolute safety" can never be reached.
>
> > axiom3: doing the same thing repeatedly and expecting different results
> > (e.g. "we have achieved absolute safety")  is insanity.
>
>Huh?
>
> > axiom4: many things are inherently dangerous
>
>Yes, but one should take as many precautions against such things as is
>reasonable to do.  I think there's been only one case in the design where I
>can actually be accused of possibly standing in someone's way in the name of
>safety... and that's with not exposing lock/unlock on the mutex types.  That
>decision is *still* under consideration, however.
>
> > I'm suggesting that we quit using "it might not be safe if misused" as a
> > mantra.  It's a consideration, that's all.  "Gee, this might be unsafe if
>I
> > misuse it...I'd better be careful."
>
>Sorry, I honestly don't feel I've done this.

semaphores are NOT in boost:threads (as near as I can tell, because of 
this).  BTW, it is absolutely clear that you canNOT write a semaphore in C 
or C++ (the necessary primitives don't exist).

> > We're not children here.  We handle dangerous things every day (knives,
> > driving, etc).
> > The language cannot protect against a lot of things that will cause the
> > program to blow up, why are we so worried about this one?
>
>Because from experience this particular area of computing is one that
>produces the largest amount of bugs, and the bugs are extremely difficult to
>detect during testing, and to diagnose and correct once detected (usually in
>production).

fortunately, code walkthru/review by _many_ peers kept us out of that 
problem for the main part.  I _do_ remember the one trip into the field to 
chase a problem of this nature (which turned out to be some code _I'd_ 
written) which was found as I was in the middle of a presentation on why 
the problem couldn't be "my fault" when I realized that, in fact, it was.

>   The need to consider safety is a little higher here then in
>other areas, even though you're still left with plenty of rope to shoot
>yourself in the foot with.

I don't want to shoot myself in the foot.  I want a FAST simple 
inter(process/thread) synchronization system.

> > as the guy in the next office said...waaaay back when:  "If you make a
> > system that even a fool can use, only a fool will use it."  Dennis J.
>Maine
>
>I appreciate your concern and opinion, and if you think I am putting safety
>above all other considerations then by all means continue to fight the
>fight.  Safety wasn't the lone consideration for rejection of the exception
>passing mechanism, though, so you'll have to argue the other points as well
>to convince me.

ok, this is philosophy time; well maybe a "point of view"

we call a function thusly:
someresult = myfunc(arg1, arg2, arg3);
Everyone agrees that it's ok for myfunc, or something IT calls, to throw an 
exception.  There are a few problems, but they appear to be well 
understood.  There isn't any asynchrony (barring OS exigencies) here.  All 
the work occurs in the thread which makes the call. Everyone is happy!

suppose I now give myfunc another name
someiostreamref = cin.getline(somecharbuffer, 50, '\n');
Nobody seriously expects all of the "work" done here to occur in the thread 
which makes the call.  It's clear that an exception may be thrown.  Nobody 
appears to have a problem with this.  Things that are NOT clear is how 
information gets passed around (and it's actually irrelevant to USING 
cin.getline()) so that the errors get properly propagated.

suppose we now move the implementation of myfunc to another machine 
(RPC?  SOAP??)
Should what the user sees have to change?  Can we throw an exception from 
myfunc?  No, yes respectively.  Of course, this requires that we come up 
with some changes to the 'standard communications interface' and figure out 
how to "pass an exception back".  When we do that (which requires 
developing a protocol for the exceptions) it becomes easy.  The "wrapper" 
on the target machine does a 
try{do_the_real_work;}catch{}catch{}catch{}catch(...){} send the proper 
"reply".

Now writing the wrapper/encoder/decoder/exception-builder is a non-trivial 
task (it's not a research project, but it's not an hour hack either)

Suppose the writer of myfunc() discovers a way to improve its performance 
by starting a couple helper threads.  If the current design includes 
exceptions, s/he is going to have to re-invent some form of the 'wrapper' 
to pass the exceptions from the child threads back to the parent and a 
wrapper to reconstruct the exception.  Naturally, the exception cannot be 
thrown until some sort of "join" function is called. Not an insurmountable 
job, but why have everyone who needs this invent their own.

I believe adding such a "wrapper" to boost::threads would be a "Good Thing".

Something similar, I believe, will need to be 'added' to any "delayed 
function" system.

>Bill Kempf
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"