In an an application I am developing (win/32, PB/DLL 6.0, SDK-style), I have a need to run a "batch" job, during which other work needs to be done.
My basic program structure is quite elementary:
Thread One = User interface (get file names, options, etc).
Thread Two = The "worker" thread, where all the batch work gets done; started when requested from thread one, posts messages back to thread one for progress bars and an 'all done' message.
But...
Because of data conflicts and dependencies, I can only run one "worker" thread at a time; consequently, I disable the ability of the user to submit a second job until the first job is completed. What I want to do now is allow the user to send multiple batch job requests and have them queue up, running one after the other.
I also want to be able to react to a "cancel jobs in queue" command by allowing the currently running batch job to complete, but not allowing any more to start.
I had a couple of thoughts about this, but they all seem kind of clunky . Example: my latest 'really good idea' involved starting a thread, which itself starts a third thread and waits for the third thread to conplete. That just seems weird to me - that is, NOT a 'really good idea.'
I worked with Mr Florent Heyworth's code from April 22, 2001 using the QueueUserAPC API function; that works really well, except I can't figure out how to "cancel" or "unqueue" a job once queued. (That code uses something like a callback to itself too; that is really confusing to me).
I'd like to avoid using a separate process because the 'worker' thread code is already set up to post those messages to Thread One. (Using a separate process was another one of my 'really good ideas' which flopped when I got to the part about the messages).
I was wondering if anyone had a ideas, notes, jottings, (psuedo-) code examples or just some thoughts as to where to look for a good way to queue up jobs. (I would not be surprised if I am missing the something really obvious, so don't be shy).
Thanks,
------------------
Michael Mattias
Racine WI USA
[email protected]
My basic program structure is quite elementary:
Thread One = User interface (get file names, options, etc).
Thread Two = The "worker" thread, where all the batch work gets done; started when requested from thread one, posts messages back to thread one for progress bars and an 'all done' message.
But...
Because of data conflicts and dependencies, I can only run one "worker" thread at a time; consequently, I disable the ability of the user to submit a second job until the first job is completed. What I want to do now is allow the user to send multiple batch job requests and have them queue up, running one after the other.
I also want to be able to react to a "cancel jobs in queue" command by allowing the currently running batch job to complete, but not allowing any more to start.
I had a couple of thoughts about this, but they all seem kind of clunky . Example: my latest 'really good idea' involved starting a thread, which itself starts a third thread and waits for the third thread to conplete. That just seems weird to me - that is, NOT a 'really good idea.'
I worked with Mr Florent Heyworth's code from April 22, 2001 using the QueueUserAPC API function; that works really well, except I can't figure out how to "cancel" or "unqueue" a job once queued. (That code uses something like a callback to itself too; that is really confusing to me).
I'd like to avoid using a separate process because the 'worker' thread code is already set up to post those messages to Thread One. (Using a separate process was another one of my 'really good ideas' which flopped when I got to the part about the messages).
I was wondering if anyone had a ideas, notes, jottings, (psuedo-) code examples or just some thoughts as to where to look for a good way to queue up jobs. (I would not be surprised if I am missing the something really obvious, so don't be shy).
Thanks,
------------------
Michael Mattias
Racine WI USA
[email protected]
Comment