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

Reply via email to