This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [setup PATCH] Another micropatch heading towardsnext_dialogremoval (1)

Robert Collins wrote:
> On Sat, 2003-07-26 at 21:31, Max Bowsher wrote:
>> Actually, no.
>> Today, we don't handle the situation because NEXT() is obsolete code that
>> fails to actually do anything.
> Well, NEXT() in this does attempt to reactivate the current dialog
> doesn't it? Gary - any input here?

That would appear to be its intent, but it is a relic of an old way of doing
things, and no longer works. (Tested by making it always-called: setup
continues on regardless)

>> After this, we kind of handle the situation, and will be able to handle
>> situation properly one we have full use of exceptions.
> It's not a situation that should warrant an exception or failure. All we
> need to do is get the correct value from the dialog.
>>> It seems better to me to loop (say max 2 times) if such a race occurs,
>>> rather than reentering the dialog or exiting.
>> Try to actually trigger it. The dialog changes so fast, it is impossible
>> do.
>> So, if a user can't trigger this oddness, the only remaining cause is
>> Windows oddness, which is good reason to bail out.
>> Actually, my preferred change would be to not try to detect this error,
>> since I don't think it can occur.
> Hmm, I'll defer to Gary on this. If he says it's impossible to occur,
> lets simplify the code. If it is possible to occur, lets Do The Right
> thing, windows oddness or not.

The race window is 2 successive SendMessage calls.
Since we are inside the OnNext handler at the time, I don't believe any more
messages to setup can be processed. Therefore, I believe we are safe.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]