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: | ||
| − | * | + | '''Date unknown, copied 25 March 2007''' |
| − | * MGR: | + | |
| − | * | + | * 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. | ||
| − | * | + | * 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. | * 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. | :• 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.
