Searched +hist:807 +hist:d3aa8 (Results 1 - 1 of 1) sorted by relevance
| /haiku/src/system/kernel/cache/ | ||
| H A D | block_cache.cpp | diff 807d3aa8 Fri Apr 04 08:02:30 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * If BFS's Journal::_WriteTransactionToLog() noticed there wasn't enough free space left for the new log entry, it did call cache_sync_transaction(), and then just assumed the space would be ready. But since the transaction could have been written before that call by the block writer, and since the _TransactionWritten() hook is now called asynchronously, cache_sync_transaction() actually has to flush all pending TRANSACTION_WRITTEN notifications before returning to the caller. * To implement this, block_cache now publishs a condition variable, and wait_for_notifications() adds a fake notification that signals that one. Since the notifications are handled in FIFO order, this guarantees that the previous TRANSACTION_WRITTEN hook is done. * notify_transaction_listeners() could accidently delete notifications that still had pending signals. Now, it will defer the deletion to the notification thread instead in that case. This should fix bug #2008. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24792 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 807d3aa8 Fri Apr 04 08:02:30 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * If BFS's Journal::_WriteTransactionToLog() noticed there wasn't enough free space left for the new log entry, it did call cache_sync_transaction(), and then just assumed the space would be ready. But since the transaction could have been written before that call by the block writer, and since the _TransactionWritten() hook is now called asynchronously, cache_sync_transaction() actually has to flush all pending TRANSACTION_WRITTEN notifications before returning to the caller. * To implement this, block_cache now publishs a condition variable, and wait_for_notifications() adds a fake notification that signals that one. Since the notifications are handled in FIFO order, this guarantees that the previous TRANSACTION_WRITTEN hook is done. * notify_transaction_listeners() could accidently delete notifications that still had pending signals. Now, it will defer the deletion to the notification thread instead in that case. This should fix bug #2008. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24792 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 807d3aa8e370f76f30ee805d7f7f3c2f558b7aa2 Fri Apr 04 08:02:30 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * If BFS's Journal::_WriteTransactionToLog() noticed there wasn't enough free space left for the new log entry, it did call cache_sync_transaction(), and then just assumed the space would be ready. But since the transaction could have been written before that call by the block writer, and since the _TransactionWritten() hook is now called asynchronously, cache_sync_transaction() actually has to flush all pending TRANSACTION_WRITTEN notifications before returning to the caller. * To implement this, block_cache now publishs a condition variable, and wait_for_notifications() adds a fake notification that signals that one. Since the notifications are handled in FIFO order, this guarantees that the previous TRANSACTION_WRITTEN hook is done. * notify_transaction_listeners() could accidently delete notifications that still had pending signals. Now, it will defer the deletion to the notification thread instead in that case. This should fix bug #2008. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24792 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 100 milliseconds