April White: > > I hope the icky debug stuff is going to disappear. > > > When I don't need it any more. I've disabled the DEBUG define so the > code it excluded.
There were problems here because __attribute__ is for gcc and confuses other compilers. > > "Copyright?" doesn't deserve a "?". > > > > > Since you gave me the example I wrote the code from, I do not feel right > in listing copyright for me. Can I/may I assign it or give it to you? OK. > > The JobQueue Lock and Unlock should be private so that callers > >can't confuse the lock state. > > > Done. I initially left them public so that the soon-to-be written code > that would allow a Lua script to add multiple commands could lock the > queue, add the commands, and then unlock the queue. Its the Lua case that I'd be scared of: if user written scripts could lock the queue for lengthy periods the whole application could hang. > I've been rethinking this position and it may not be an issue. The > queue is only locked at it is modified, so while a command is actually > running, other commands can be added, which will run when the current > job is completed. It only matters if you want a set of commands to execute in sequence, depending on each other and an interfering command could be inserted from somewhere else. I don't think this has to be worried about for now. > I am thinking about changing how the jobs are executed. I'm thinking of > removing the code that sends a message to the window and merely check if > the queue is not empty. By checking when it was last checked, and only > doing the check every fraction of second, it should not have a drag on > resources. The IDM_FINISHEDEXECUTE processing is fairly heavy so you don't want to execute it multiple times and there shouldn't be too much of a delay before the UI is reenabled. I expect your work wil fix bug 1156797 since commands are popped from the queue before being executed. https://sourceforge.net/tracker/index.php?func=detail&aid=1156797&group_id=2439&atid=102439 Neil _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest