[SERVER-1819] audit usage of checkForInterrupt to ensure all exceptions handled cleanly Created: 21/Sep/10  Updated: 02/Mar/17  Resolved: 02/Mar/17

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-4227 audit killop support Closed
is related to SERVER-1818 make sure checkForInterrupt() excepti... Closed
Operating System: ALL
Participants:

 Comments   
Comment by Eric Milkie [ 02/Mar/17 ]

I don't expect to do any further work for this ticket. The redesign of transactions with support for rollback in both mmap and WiredTiger has reduced the chance for bugs in this area.

Comment by auto [ 05/Oct/10 ]

Author:

{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}

Message: SERVER-1819 remove timing dependent tests from parallel suite
http://github.com/mongodb/mongo/commit/ac7d7286e7b2e9ec03b636fe811d4ab98302ea9a

Comment by Aaron Staple [ 05/Oct/10 ]

Unfortunately this is not yet a complete fix. There appear to be at least some cases where interrupting during a yield() can lead to an inconsistent state.

In addition, Dwight suggested we could check for interrupt in the following situations:

  • we are in a write op, but no write has occurred yet
  • we are in a write op, and are committing the current view
Comment by auto [ 05/Oct/10 ]

Author:

{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}

Message: SERVER-1819 limit interrupt code paths when write lock held
http://github.com/mongodb/mongo/commit/e0590db4d1f2ab389ca589109eaa386007b1d2ca

Comment by Dwight Merriman [ 24/Sep/10 ]

One approach, which would be the safest, would be to simply make checkForInterrupt() NOT interrupt on a write operation, and simply require long write ops to call KillCurrentOp::checkForInterruptNoAssert() at appropriate times.

In addition clientcursor::yield() could call checkForInterruptNoAssert() and abort the entire op, as that is a safe place.

the above approach would have no risk of a mistake that yields corruption, but would trade off for a risk of a non-interruptible operation – probably a good thing.

Generated at Thu Feb 08 02:58:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.