/reportdesign/qa/

Age	Commit message (Collapse)	Author
2019-03-14	Fix scheduled Task priority change handling	Jan-Marek Glogowski
	If a task is still in the scheduler priority queue and its priority is changed, it won't be moved into the correct queue. We have to track the priority of the scheduled task, so we can warn the developer to fix the code and actually handle re-start correctly. Since we don't want to traverse the whole Scheduler queues on priority change (which sometimes get very long) to remove the wrong data item, we'll just invalidate it, if a priority change is detected. This also reverts commit d24b264c4a47 ("vcl opengl: avoid task priority warning on cursor blink"), which tried to avoid the warning, which was just half right and independent of the broken priority change handling. LO doesn't change priorities of scheduled tasks normally, so that bug didn't turn out to have much impact, I guess. Change-Id: I6e46b518a7c3532047c619c013bd8597f73ed7a6 Reviewed-on: https://gerrit.libreoffice.org/69249 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-23	loplugin:includeform: vcl	Stephan Bergmann
	Change-Id: Id7dea3917740aaf4db8dada5e2bea6e117d714ea
2017-08-09	osl::Mutex::acquire can effectively only fail upon programming errors	Stephan Bergmann
	...so simplify the design a bit here (and there was no meaningful failure- handling code, anyway) Change-Id: I34bb3a7b5fc56f2213a4d22438f0733e1b65fe4b
2017-08-04	Implement VCL Scheduler locking	Jan-Marek Glogowski
	Replces the SolarMutex scheduler locking by using a distinct mutex included in the scheduler context. It should also get rid of the spurious assert( !bAniIdle ) failures, as the test now holds the Scheduler lock for the whole time. This includes reverting the additional scheduler de-init from commit 2e29a518b04250b5f9cc9d0d77da3df076834d60, as I couldn't reproduce the bug running the unit test in valgrind. Change-Id: If33f815fe86c8f82175e96adceb1084b925319dd Reviewed-on: https://gerrit.libreoffice.org/40497 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>