Andrew Chernow wrote:
> Rainer Bauer wrote:
>> "Matthew T. O'Connor" wrote:
>>
>>> Tom Lane wrote:
>>>> ROTFL ... so to translate: "If your program crashes, please release
>>>> locks before crashing."
>>> Obviously that wasn't the intent of the above, but I guess it is the
>>> net effect. Either way, I don't think it's a huge problem, it just
>>> means that PG may not be able to restart for a few seconds until the
>>> OS has time to clean-up the locks.
>>
>> I don't think so. I am using DevStudio 2005 here and from time to
>> time the
>> debugger crashes so that I have to kill the program via the task
>> manager.
>> Afterwards it's not possible to load the crashed project again in a
>> newly
>> started DevStudio session, because some project files are still locked
>> exclusively. The only action that helps is rebooting windows.
>>
>> Now, I don't know whether DevStudio is using LockFileEx() but somehow
>> this
>> sounds familiar.
>>
>> Rainer
>>
>
> Has anyone considered not using a file lock on windows? CreateMutex
> might do the trick if provided a mutex name, making it global rather
> than process bound. OpenMutex can be used to test if the mutex exists
> or if it is currently locked. I guess it would stay locked. If there
> is a crash, it is automatically closed by the os.
>
> The docs state the system closes the handle (mutex) when the process
> terminates and makes no mention of this being a lingering action like
> LockFileEx. It sounds like the mutex is closed ASAP when the process
> terminates, just like file handles.
>
Please review the previous discussion. This whole thing came about
because of major problems in handling Global objects.
cheers
andrew