|
Post by MUEH on May 24, 2017 13:11:17 GMT -5
George: First occurs the Crash Interset Popup window with Execution exception followed after 10 sec later by the Loop intecept . I sent an msg with the test data and how to recreate . Thanks
|
|
|
Post by George on May 25, 2017 10:54:23 GMT -5
MUEH: OK, I've finally tracked this down. The problem is triggered by an Err=7 Out of Memory condition as SPFLite tries to expand the data areas needed to hold the edit data. And, as it turns out it is NOT a simple out of memory condition, there's plenty of memory available. The program is running out of Stack space. The data areas are not allocated on the stack, so what is using it up?
It turns out to be caused by the file-watch routines; which monitor the files being edited for external changes. In the test data you provided, there are 1132 files for MEdit, which means that many file-watch threads to be created. I wasn't aware of this, but obviously creating threads like this chews up stack space.
I temporarily crippled the creation of these threads, and your test data now loads successfully, all 1132 files and about 1,250,000 data lines. But it does take some time; on my system it was at least 5-6 minutes. Once loaded, working with the file seemed pretty reasonable. My only caveat is to avoid excessive use of X/NX, they will be slow, I'm sure.
So, what to do? Since I'm pretty sure that using MEdit on a very large number of files is rare, and the chance of external modification while this is being done is even rarer, I'm going to issue a pop-up saying what's happening, and that File-Watching is being turned off. I really can't think this will be a problem for anyone.
So now -- off to figure out just how to toggle this built-in automatic function on and off. I figure I'll do this if the # of files is over 100.
George
|
|
|
Post by MUEH on May 26, 2017 9:31:11 GMT -5
George: Sent email showing new all B problem with more than 35 files after 8.5.7145 Thanks
|
|
|
Post by George on May 26, 2017 13:27:12 GMT -5
Robert: Yes, I'm fully aware only one thread per folder is needed. The watch routines are currently intertwined with the Tab and global level filename queuing logic. Re-designing that structure, the thread routines and the callback functions to use 1 thread per folder is not likely to make my agenda. This situation with such a large number of files is unusual, and I don't think it justifies such a major revision. I don't see running without file-watch in this case is much of an exposure.
George
|
|
|
Post by MUEH on May 26, 2017 13:48:14 GMT -5
George: Another Problem with 8.5.7145 . when M-Edit Tab has f.e 32 files ( x 1100 largest from test data ) and you click on Tab with right mouse key to terminate tab SPFLite hangs without consuming cpu time .
|
|
|
Post by MUEH on May 27, 2017 12:06:00 GMT -5
George: Thanks for 8.5.7146 . It solved the last M-Edit Problems . I accept that all B E V for more than 215 -225 files result now in crash . Previously no data was in Tab . One thing you might correct is # of lines at bottom of screen . If they are greater than 99999 last Digit is unreadable even Txt shifted one byte left . Thanks for great new features .
|
|
|
Post by George on May 27, 2017 14:15:24 GMT -5
MUEH: How on earth do you manage having a couple of hundred tabs open? The normal left/right tab scrolling isn't too swift with that many tabs. Or do you use the FM OPEN display to locate and switch tabs? I guess defining a key as RC OPEN would make getting back to the OPEN display a little faster.
If you really do work with that many tabs regularly, maybe I will have to consider what Robert suggested to re-write the FileWatch routines.
George
|
|
|
Post by MUEH on May 27, 2017 15:00:51 GMT -5
George: Sorry i don't need so many tabs . I only made the all B command to see if it can Process the Files failing with the 500 Medit file limit . I'm happy as it works now.
|
|
|
Post by George on May 28, 2017 11:18:46 GMT -5
MUEH: OK, I was puzzled at how anyone could manage that many tabs effectively. Actually, I've re-read the help on creating threads, and I may experiment with passing an optional parameter to specify the thread's stack size. If omitted, it says it uses the stack size of the main process, which is way more than a single small thread would need. This may alleviate this whole running out of stack space problem. I'd never noticed this parameter before.
George
|
|