From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Advice, tasking and hardware
Date: Fri, 27 May 2016 16:09:36 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <niajsl$6bs$1@dont-email.me>
References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com>
 <ni68f8$1t85$1@gioia.aioe.org> <ni7iue$v9b$1@dont-email.me>
 <ni8u8j$1h74$1@gioia.aioe.org> <nia5lo$oik$1@dont-email.me>
 <niagbh$12t$1@loke.gir.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 27 May 2016 23:05:59 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="48b46be33beed75863f69afa437f956b";
	logging-data="6524"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+fcqOVRLhIZ4yK//TdE9RV/t5TqwL3gfE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
In-Reply-To: <niagbh$12t$1@loke.gir.dk>
Cancel-Lock: sha1:iDSGift5556lsGm4lGiTK+iPbFY=
X-Enigmail-Draft-Status: N1110
Xref: news.eternal-september.org comp.lang.ada:30498
Date: 2016-05-27T16:09:36-07:00
List-Id: <comp.lang.ada>

On 05/27/2016 03:05 PM, Randy Brukardt wrote:
> 
> Huh. Most people *aren't* competent to develop concurrent software -- it's 
> way too hard and (unlike sequential code) the compiler and language is no 
> help. (Race conditions and deadlocks are trivial in Ada code; very little 
> practical code doesn't have them.). But most of us have to develop such 
> software anyway, whether or not we're competent.

Most people aren't competent to develop any software. That doesn't make it
acceptable that some incompetent is creating yet another buffer-overflow
vulnerability right now. I don't suppose there's any way to stop such people,
but we shouldn't encourage them.

> [Especially as I've never figured out how to properly shut down the tasks in 
> any of my service programs. Maybe I could have figured out something, but it 
> would have greatly complicated an already complicated system. Instead, I 
> kill the process manually in the rare case that I need to restart a service 
> (and I also have a watchdog program that kills and restarts non-responsive 
> services, and triggers a full system reboot if that doesn't work - that 
> probably would be needed in any case, just to keep services up as much as 
> possible {in case of DoS bugs}). A club rather than a screwdriver, but a lot 
> easier.]

I suspect it's a characteristic, if not a requirement, for these programs that
they be able to die suddenly without harm. Would you have taken the same
approach if not shutting down cleanly would cause problems? (I designed the
shutdown mechanism for a program with hundreds of tasks that ran as a service.
The program intercepted the signal sent by the service stop command, and
everything terminated cleanly as required.)

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77