Re: My apologies for flooding this newsgroup...

Hector Santos wrote:
On Nov 13, 12:05 pm, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
"Hector Santos" <sant9...@xxxxxxxxx> wrote in message

news:1194968998.498589.91060@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Nov 13, 7:55 am, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
"Hector Santos" <sant9...@xxxxxxxxx> wrote in message
news:1194936864.347689.286380@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 11, 8:24 pm, Logan Shaw <lshaw-use...@xxxxxxxxxxxxx>
wrote to Chris Thomasson wrote:
There's no need to apologize for casting your pearls before swine.
They're your pearls, if indeed they are pearls in the first place,
and not anyone else's concern, really. In fact, the only reason I
can imagine you may have posted that part of the "apology" is to
gain sympathy. You're apparently trying to drag other people into
the discussion and convince them to take your side by making a play
for the moral high ground with a token apology, despite the fact
that you obviously have no intention to change the behavior you
claim to be sorry about.
The sad fact is that he continues to flood the Microsoft newsgroup
with this rthetoric. The kid is a troll. Smart, but its time to grow
up Chris. You don't have a copyright or patent on software
engineering issues.
Why don't you want to fix the problems I found with your code?
[...]

When are you going to get this a rest?
The following constructor code of yours is bugged:

inline TReaderWriter::TReaderWriter()
{
Readers = -1;
ReadingOk = CreateEvent(NULL, TRUE, TRUE, NULL);
ReadingActiveSemaphore = CreateSemaphore(NULL, 1, 1, NULL);
WriterRecursion = 0;
}
You code fails to check if CreateEvent/Semaphore actually succeeded. I don't
care what your 6 engineers say, they are obviously wrong.

Who agrees with me here?

As it as explained to you for the UMPTHEEN time, for this to fail, I
presume you are thinking low memory, not only will the constructor
would fail upon instantiation, but the entire system would have to be
completely unstable which is a whole different engineering resolution
already under control.

Which part don't you understand?

On any rational multiuser/multiprocess system, there is some form of quota mechanism to prevent a user or application from oversubscribing shared resources. I'm not a Windows programmer, and a google for documentation of CreateSemaphore showed no useful information at all (call GetLastError if it returns NULL, sure... but no indication at all of WHY that might happen. Idiotic)... but, for example, on a UNIX system or most any large enterprise system, you might hit the system or user limit on semaphores, while everything else will be running just fine.

There may be reasons you think this doesn't apply to you. Assuming the credentials of the application in question aren't fabricated (a possibility I don't entirely discount), you may even be correct. Maybe Windows doesn't have such quotas at all and simply lets you acquire resources until either the process or system crashes -- in which case clearly testing would be pointless. Or perhaps your application runs in only a limited and carefully configured system where you know that only it will consume semaphores, the system has at least <n> semaphores available, and the application will never use more -- in which case checking for that error would clearly be a waste of time.

Generally, though, the rule is that you should always check for errors that may happen for reasons the application code cannot predict or control. Process and thread quotas, or disk space, for example; or, for MOST applications, semaphores, may be claimed asynchronously by any of a number of different agents beyond the knowledge or control of a typical application -- failing to check for such errors is generally just irresponsible.

One exception is an application that has no persistent state. If it doesn't finish cleanly, it has no external effect. No abandoned kernel resources, temporary disk files, or anything else that a robust application might ordinarily wish to clean up on an abnormal termination. If you can't recover and continue, it may be easier (possibly even "best") to just crash and let someone start over.

So, somehow, I guess you must be indirectly intending to argue that these potential failures can be caused only by circumstances entirely within your application's control; or that your application has no persistent side effects and you (and your customers) are just willing to accept that the occasional bizarre failure mode can be restarted.

In either case, though, you could probably respond with a bit more reasoned rebuttal. And, Chris; you're basically repeating the same taunt, and not even in particularly unique ways. We all get the message. If you're not right, it's because of special circumstances that your playground buddies haven't explained. But, really, so what? If their application is busted in incredibly stupid ways and absolutely never works correctly, why does it bother you? And if there are really reasons that the operational restrictions are acceptable, or even appropriate, for their environment, how is all this fuss helping anyone?

What I hear from you guys amounts to little more than school children shouting back and forth on the playground "I'm rubber, you're glue; whatever you say bounces off me and sticks to you." Amusing, perhaps, the first 2 times through, for other school children. But really utterly pointless. If you must rant and rave at each other, take it to private email.

Please believe me, none of you are making any points posting this publicly.
.