Created by Rick Downes (mozilla@radsoft.net) on Thursday, July 16, 1998 6:15:35 AM PDT Additional Details : Seems you guys haven't really gotten multithreading. Nowadays you've got so much going on in this mutating app that even at exit there are threads running, accessing things which other threads do their politest to clean up and destroy. With all these threads running you must find a way of synchronising the ExitProcess call, either directly or indirectly, by waiting on all running threads to exit, signalling them first of the shutdown. Several times your app has actually been running in the background, totally invisible, several seconds realtime after it disappeared from the screen. In this case if it is opened again, one of three things can result (so far): 1.) It just doesn't open. Period. 2.) It opens and disappears just as fast - like a flash on the screen. 3.) (Most often) - it crashes ALL OVER THE PLACE. These successive crashes, caused by the structured exception handling, show something is DIRELY wrong, A.) You have no build-in handler at all, B.) some thread is accessing something which has been removed from you process page tables subsequent to the DestroyWindow and its follow-ups. Updated by Garrett Arch Blythe (blythe@netscape.com) on Tuesday, July 21, 1998 2:48:12 PM PDT Additional Details : Yes, this sucks.

Suggestion: use a special "shutdown" manual reset event in the Windows FE to catch this stuff. Let all looping running threads call WaitForSingleObject with a timeout value of ZERO on this sucker. If the return value is WAIT_OBJECT_0 then the thread knows it's time to blow the pop stand.

batch-reassigning all Garrett Blythe bugs to Don Melton

Accepted bug as ASSIGNED. Hmmmm ...

Setting all current Open Critical and Major to M3

Resolved as WONTFIX. The Mozilla classic codebase is essentially dead.

marking as verified since this is against old code