Re: IPC resource access counting problem
#define ZERO_BASE 10000 //max file opens before a wait happens
Calling something at is non-zero with a name that says it is ZERO is very confusing
Why a pointer? Why not just a CSemaphore?
Well I didn't really submit this for an off topic code review, I just
posted it for illustration. Anyway...the name doesn't say it's zero,
it says it's a zero base. The reason for a pointer was because of the
fact I need to remove "\\" from the filename. It would have been nicer
just to extend CSemaphore otherwise.
By the way, NOBODY trusts the MFC
implementations of the synchronization primitives; most of them are so bug-ridden that it
is impossible to use them at all.
For my purposes of not requiring extreme robustness it's better to
follow principles of simplicity, code reuse and letting the system do
the hard work, i.e. what MFC is for. There doesn't seem to be any bugs
affecting what I need.
FileDeleter(CString fName) : filename(fName)
Note that this has numerous problems. For example, this can never block until 10,000
instances of the program have tried to delete the file already.
I don't want it to block. In fact I should have just used LONG_MAX
here rather than 10000. I'm just piggy backing on a semaphore to
provide an IPC counter.
Note that this suffers from the same problems as most of the other proposals: if the
program crashes without callling Unlock(), then nobody notices there are one too many
instances running and you end up never deleting the file.
Of course. Your solution isn't 100% robust either as I understand it.
I'm not interested in excessive robustness here for the price of a
complex, convoluted non-scalable solution or writing something using
virtual assembly statements. All I'm doing is making some attempt to
keep the tmp folder clean.