Wait-free MPSC and MPMC implement in D

[Jonathan M Davis]

On Wednesday, May 09, 2018 07:13:08 Shachar Shemesh via Digitalmars-d wrote:
> I have a motto in life - if you assume you're great, you most likely
> aren't. I have grown out of the "my code has no bugs" phase of my life
> quite a while ago.

The scary truth is that no matter what you do, you're likely going to have
bugs in your software that you've simply never found, and they could be
minor issues that will never matter or major issues that could completely
blow up in your face later. There are plenty of steps that we can and should
take in order to try to write software without bugs, but even if we somehow
manage to write a piece of software that has no bugs (which is _highly_
unlikely in any software of any real size), we have no way of knowing that
we've reached that point. A lack of bug reports just means that no one has
reported a bug, not that we don't have any.

> The fact that code is used, to good effect and for a long period of time
> does not mean that it doesn't have problems, some of them might be quite
> fundamental.

A great example of this would be openssl. It's used by huge amounts of
software and yet it's terrible software.

Stuff like operating systems have bugs reported on them all the time, and
those often have thousands of developers and millions of users.

> fundamental. "This code is highly tested" is not a good answer to "I
> think I found a problem".

Yeah. Thorough testing is a great sign (and a lack of testing is a very bad
sign), but it's not a silver bullet. It's easy to do what looks like very
thorough testing and find that you've missed stuff when you actually look at
the code coverage. And 100% code coverage doesn't mean that that you caught
everything, just that you're actually running tests that touch all of the
parts of the code.

std.datetime had very thorough test coverage when it was first released, but
at least one bug still crept through (and was fortunately found later). I
have no clue whether there are any bugs left. I hope not, but there's no way
to know, and any time I touch the code, I risk adding more bugs, even if I'm
fixing other problems.

dxml had 100% test coverage (or as close as is possible anyway), and yet
when Johan passed it through ldc's fuzzer, it found three cases where I'd
failed to call empty before calling front which had not been caught by the
tests. Maybe it has more such problems, maybe it doesn't. And it may or may
not have other bugs. I have no way to know, and on some level, that's a bit
unnerving, but it's just how life goes as a software developer.

If someone finds a bug in my software, I want to know about it. It's quite
possible that what someone is pointing out is invalid (e.g. when Johan first
fuzz-tested dxml, he'd used the API incorrectly, violating the pre-condition
for a function he was calling, so what he initially found was not a bug),
but if we have any hope of even approaching perfect software, we need to
know about the problems that are found so that they can be fixed. And to an
extent, a lack of bug reports indicates a lack of use, not a lack of bugs.

> So, my plea is this. If you find an area worth improving in Mecca,
> please don't hesitate to post. If you find you do hesitate, please
> please feel free to send me a private message.

I second this for any libraries that I make available and would hope that
this would be the attitude of anyone releasing software. There are plenty of
cases where folks disagree on where things should go and what is or isn't a
bug, but we need to know where the problems are if we have any hope of
fixing them.

- Jonathan M Davis