D
dbeavon
Guest
>> any crash of the AVM should be reported to Tech Support. I just now submitted this. It was a bit hard to get it to happen under normal circumstances, so I had to artificially increase the number of concurrent client processes that were making attempts to read the r-code. As a side... Initially I thought the problem was going to be related to my class inheritance. IE I was guessing that the bug would be a result of the unusual way in which the compiler may save *multiple* files at once - even ones that were NOT requested.... But it turned out that the bug had nothing to do with that at all; it can even happen when working with ABL code which doesn't use inheritance. Another thing occurred to me while building the repro ... the bug can probably happen when only *one* party is doing the COMPILE/SAVE. The other party might not even be compiling code, but just trying to *execute* something that hasn't been fully written to disk yet. IE. this seems like a fundamental problem with COMPILE/SAVE in cases where it is used in a shared environment (ie. an environment where there are multiple active processes sharing the same propath). I had no idea that there was a possibility that another AVM client process might crash if a COMPILE was underway. I always thought that the writing of r-code was somehow "atomic" and/or that other client processes would revert to using the ABL source code if ever something went wrong while attempting to use the r-code. >> one strategy we often use for preventing applications from using partially written files is to write the file under a different name, then rename it when done. I will pass that along as a suggestion for Progress to improve the behavior of COMPILE. IMHO the behavior of that operation should be atomic from the standpoint of any outside observer. The reading or executing an incomplete r-code file is not good for anyone.
Continue reading...
Continue reading...