Difference between revisions of "Change Log 5.8.3"

From BOINC Wiki
(adding 5.8.3)
 
m (adding date)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
* manager: use user-friendly app names (fix to work w/ 5.4.11)
+
'''Date unknown, copied 25 March 2007'''
* MGR: Possble fix for the Simple GUI messages dialog?
+
 
* manager: don't prepend "(Activities suspended by user)" to result status. There is no longer a notion of "activities"
+
* MGR: use user-friendly app names (fix to work w/ 5.4.11)
 +
* MGR: Possible fix for the Simple GUI messages dialog?
 +
* MGR: don't prepend "(Activities suspended by user)" to result status. There is no longer a notion of "activities"
 
* MGR: Copy missing source file from HEAD branch for Frank Weiler's pie charts updates.
 
* MGR: Copy missing source file from HEAD branch for Frank Weiler's pie charts updates.
 
* MGR: Streamline the message dialog sync operation a little bit.
 
* MGR: Streamline the message dialog sync operation a little bit.
* core client: lots of debugging messages for cpu_sched (may remove later)
+
* client: lots of debugging messages for cpu_sched (may remove later)
* Manager: check for ERR_DB_NOT_UNIQUE, not ERR_NONUNIQUE_EMAIL
+
* MGR: check for ERR_DB_NOT_UNIQUE, not ERR_NONUNIQUE_EMAIL
 
* Update libCurl to 7.16.0 and use sync name resolves instead of async name resolves.
 
* Update libCurl to 7.16.0 and use sync name resolves instead of async name resolves.
* core client: fix a bug that could cause computation to stop.
+
* client: fix a bug that could cause computation to stop.
 
:• The problem: if we suspended a task by sending it a <quit/> message, we were changing its scheduler state to CPU_SCHED_PREEMPTED but not changing its task state (PROCESS_EXECUTING). If, for some reason, the process didn't exit right away, the scheduler would treat it as still running, since it builds its "currently running" list based on task_state.
 
:• The problem: if we suspended a task by sending it a <quit/> message, we were changing its scheduler state to CPU_SCHED_PREEMPTED but not changing its task state (PROCESS_EXECUTING). If, for some reason, the process didn't exit right away, the scheduler would treat it as still running, since it builds its "currently running" list based on task_state.
  
 
:• Solution: the scheduler shouldn't be looking at task_state. Use scheduler_state instead. It's still a mystery why the app wasn't quitting.
 
:• Solution: the scheduler shouldn't be looking at task_state. Use scheduler_state instead. It's still a mystery why the app wasn't quitting.

Latest revision as of 16:41, 28 May 2016

Date unknown, copied 25 March 2007

  • MGR: use user-friendly app names (fix to work w/ 5.4.11)
  • MGR: Possible fix for the Simple GUI messages dialog?
  • MGR: don't prepend "(Activities suspended by user)" to result status. There is no longer a notion of "activities"
  • MGR: Copy missing source file from HEAD branch for Frank Weiler's pie charts updates.
  • MGR: Streamline the message dialog sync operation a little bit.
  • client: lots of debugging messages for cpu_sched (may remove later)
  • MGR: check for ERR_DB_NOT_UNIQUE, not ERR_NONUNIQUE_EMAIL
  • Update libCurl to 7.16.0 and use sync name resolves instead of async name resolves.
  • client: fix a bug that could cause computation to stop.
• The problem: if we suspended a task by sending it a <quit/> message, we were changing its scheduler state to CPU_SCHED_PREEMPTED but not changing its task state (PROCESS_EXECUTING). If, for some reason, the process didn't exit right away, the scheduler would treat it as still running, since it builds its "currently running" list based on task_state.
• Solution: the scheduler shouldn't be looking at task_state. Use scheduler_state instead. It's still a mystery why the app wasn't quitting.