Neil Hodgson wrote:
The implementation of Jobs::JobList::HasParameterisedCommand and
Jobs::HasParameterisedCommand need "const" to match the header.
Fixed. I must have uploaded before trying to compile.
commandMax and commandCurrent should disappear
Already done. The commandMax variable only appears within a commented
block of code. When I do not need that anymore, it'll be removed.
and some of the other fields (cancelFlag?) should be inside JobQueue.
TODO: cancelFlag, jobUsesOutputPane
Some processing
has been moved from SciTEBase::Execute in the UI thread to
SciTEWin::ProcessExecute in the tool thread which has increased the
chances of a thread clash.
TODO: I need to go back over what I did and rethink it.
calls to props.GetInt (win95.death.delay and
output.scroll) have crawled into the tool thread which is unsafe as
the property set could be reloaded by the UI while the tool is running
inside the props.GetInt call. Everything the tool thread needs should
be put in the Job or JobQueue object and protected with the lock.
TODO: add read-only methods for these two properties to JobQueue class,
add a method that initializes them, and re-initialize them after all
properties are reloaded
The queue class should be called JobQueue rather than Jobs and be housed in JobQueue.h and JobQueue.cxx
Done
the header should not be included in SciTEBase.h but rather in every .cxx file
that needs to
see this.
Done.
Mutex.h should not be included twice in WinMutex.cxx.
Done. oops.
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.
"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?
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.
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.
The destructor should lock just in case the other thread is still active when
the queue is being torn down.
Done. Thank you catching this!
When I have more stuff done on the TODO list above I'll re-post my code.
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.
April
--
Why don't ease, lease, and please sound alike?
_______________________________________________
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
