| 1 | = Core client: main loop logic = |
| 2 | |
| 3 | The main loop of the core client repeatedly calls the following function: |
| 4 | |
| 5 | |
| 6 | {{{ |
| 7 | bool CLIENT_STATE::do_something() { |
| 8 | bool action=false; |
| 9 | |
| 10 | if (check_suspend_activities()) return false; |
| 11 | action |= net_xfers->poll(); |
| 12 | action |= http_ops->poll(); |
| 13 | action |= file_xfers->poll(); |
| 14 | action |= active_tasks->poll(); |
| 15 | action |= scheduler_rpcs->poll(); |
| 16 | action |= start_apps(); |
| 17 | action |= pers_xfers->poll(); |
| 18 | action |= handle_running_apps(); |
| 19 | action |= handle_pers_file_xfers(); |
| 20 | action |= garbage_collect(); |
| 21 | write_state_file_if_needed(); |
| 22 | return action; |
| 23 | } |
| 24 | }}} |
| 25 | This function initiates new activities as needed, and checks for the completion of current activities. It is to be called periodically from either a sleep loop (command-line program) or timer handler of event loop (GUI program). It returns true if any change occurred, in which case it should be called again without sleeping. |
| 26 | |
| 27 | The various functions called are as follows: |
| 28 | |
| 29 | '''check_suspend_activities''' checks for conditions such as recent mouse/keyboard input, or running on batteries, in which user preferences dictate that no work be done. |
| 30 | |
| 31 | '''net_xfers->poll(), http_ops->poll(), file_xfers->poll() |
| 32 | and pers_xfers->poll()''' manage the internal transitions of the various FSM layers. |
| 33 | |
| 34 | '''start_apps()''' checks whether it's possible to start an application, i.e. a CPU slot is vacant and there's a result with all its input files present. If so it starts the application. |
| 35 | |
| 36 | '''handle_running_apps()''' checks whether a running application has exited, and if so cleans up after it. |
| 37 | |
| 38 | '''handle_pers_file_xfers()''' starts new file transfers as needed. |
| 39 | |
| 40 | '''garbage_collect()''' checks for objects that can be discarded. For example, if a file is non-sticky and is no longer referenced by any work units or results, both the FILE_INFO and the underlying file can be deleted. If a result has been completed and acknowledged, the RESULT object can be deleted. |
| 41 | |
| 42 | '''write_state_file_if_needed()''': any of the above functions that changes state in a way that should be written to client_state.xml (e.g. that needs to survive this execution of the core client) sets a flag '''client_state_dirty'''. write_state_file_if_needed() writes client_state.xml if this flag is set. |
| 43 | |