1

Topic: How correctly to do preemptive subroutines

And also subroutines with show  progress in %? There is a certain subroutine which does something useful and long. How performance of this subroutine is safe to cancel it? The pseudo-code: void process_school (School& school) {for (class: school.classes ()) {process_class (class);}} void process_class (Class& class _) {for (student: class _) {process_student (student);}} void process_stundent (Student& student) {//...} Let's tell, at school of 1000 classes, and in  to 50 students. Time on  each student - 10 seconds of Voobshchem, function (or a method) process_school () will long work. The client launches this subroutine in a separate flow. How it is safe to implement interruptibility these are subroutines? What general approaches for this purpose exist? While it is implemented by means of a helper class, with the help  (, a question in comments): struct ICallback {virtual bool ReportProgress (int percent) = 0;//On an input accepts current progress in %, on an output true - to continue process, false - to complete}; ICallback* g_callback; class progress_helper {int m_expected_steps;//Expected number of steps in current subtasks int m_current_step;//the Current step to current subtasks public: int calculate_current_total_progress ();//a Certain method which calculates and returns current progress (number from 0 to 100 %) progress_helper (int expected_steps): m_expected_steps (expected_steps), m_current_step (0) {if (! g_callback. ReportProgress (calculate_current_total_progress ())) {throw std:: runtime_error ("required job abort");//Or to use the special type JobAbort}} void step () {++ m_current_step; update_current_progress ();//a Certain method, which updates current progress (number from 0 to 100 %) if (! g_callback. ReportProgress (calculate_current_total_progress ())) {throw std:: runtime_error ("required job abort");//Or to use the special type JobAbort}}}; void process_school (School& school) {progress_helper school_progress (school.get_class_count ()); for (class: school.classes ()) {process_class (class); school_progress.step ();}} void process_class (Class& class _) {progress_helper class_progress (school.get_student_count ()); for (student: class _) {process_student (student); class_progress.step ();} } void process_stundent (Student& student) {progress_helper student_progress (3); process_name (student.name); student_progress.step (); process_surname (student.surname); student_progress.step (); process_sex (student.sex);//:) student_progress.step ();} //Actually creation of classes progress_helper on a stack can//be cascaded, that is, for example, if at school of 10 classes,//that progress_helper (in a method process_school) "ticks" 10 steps,//will already correspond to each step of 10 % of progress//In function process_class at creation progress_helper it//will "tick" in  10 %, that is the first time from 0 % to 10 %, the second time from 10 % to 20 % and so on.//Leaking  progress it is split up for number of expected steps, in helpers of nested functions already work//with leaking  "" and divide already it.//But how it is calculated  is not an essence important. //that by a call of the designer or a method step () progress_helper with the help  is important (too it is not important what - pointer on the virtual interface, or a lambda)//if in  solved (that is on the causing side) - that suffices, it is time are brief and returned false,//that is thrown out a certain exception, and a current flow  natural  (with interception of expected exception JobAbort).//it is not necessary to "kill" in that case a flow  by means of OS means.//the Minus of this approach that it is necessary to place type local variables progress_helper on a stack of each function.//What already there are tested decisions for this purpose?

2

Re: How correctly to do preemptive subroutines

3

Re: How correctly to do preemptive subroutines

But the offered approach (with manual pacing on cycles and saving of a state of bypass between step calls) too it is possible, and normally even it is more preferable.

4

Re: How correctly to do preemptive subroutines

5

Re: How correctly to do preemptive subroutines

Hello, GhostCoders, you wrote: GC> and also subroutines with show  progress in %? GC> There is a certain subroutine which does something useful and long. GC> as performance of this subroutine is safe to cancel it? And what if to launch it in the virtual machine and to control /// process through that API and those means that is at the virtual machine?

6

Re: How correctly to do preemptive subroutines

Hello, loginx, you wrote: L> and what if to launch it in the virtual machine and to control /// L> process through that API and those means that is at the virtual machine? Well, it is possible on C# to write - there is yield return

7

Re: How correctly to do preemptive subroutines

Hello, Mr. Delphist, you wrote: MD> Hello, loginx, you wrote: L>> and what if to launch it in the virtual machine and to control /// L>> process through that API and those means that is at the virtual machine? MD> well, it is possible on C# to write - there there is yield return it not how you will implement them in another's floor-mat.   - speech about difficult durable calculations