Is this thread.abort() normal and safe?

by

No, it is not safe. Thread.Abort() is sketchy enough at the best of times, but in this case your control has no (heh) control over what’s being done in the delegate callback. You don’t know what state the rest of the app will be left in, and may well find yourself in a world of hurt when the time comes to call the delegate again.

Set up a timer. Wait a bit after the text change before calling the delegate. Then wait for it to return before calling it again. If it’s that slow, or the user is typing that fast, then they probably don’t expect autocomplete anyway.

Regarding your updated (Abort()-free) code:

You’re now launching a new thread for (potentially) every keypress. This is not only going to kill performance, it’s unnecessary – if the user isn’t pausing, they probably aren’t looking for the control to complete what they’re typing.

I touched on this earlier, but P Daddy said it better:

You’d be better off just implementing
a one-shot timer, with maybe a
half-second timeout, and resetting it
on each keystroke.

Think about it: a fast typist might create a score of threads before the first autocomplete callback has had a chance to finish, even with a fast connection to a fast database. But if you delay making the request until a short period of time after the last keystroke has elapsed, then you have a better chance of hitting that sweet spot where the user has typed all they want to (or all they know!) and is just starting to wait for autocomplete to kick in. Play with the delay – a half-second might be appropriate for impatient touch-typists, but if your users are a bit more relaxed… or your database is a bit more slow… then you may get better results with a 2-3 second delay, or even longer. The most important part of this technique though, is that you reset the timer on every keystroke.

And unless you expect database requests to actually hang, don’t bother trying to allow multiple concurrent requests. If a request is currently in-progress, wait for it to complete before making another one.

More Related Contents:

  1. Task vs Thread differences [duplicate]
  2. Multi-threaded splash screen in C#?
  3. reference assignment is atomic so why is Interlocked.Exchange(ref Object, Object) needed?
  4. Is the ++ operator thread safe? [duplicate]
  5. Reliably stop System.Threading.Timer?
  6. C# : What if a static method is called from multiple threads?
  7. Proper way to implement a never ending task. (Timers vs Task)
  8. Cancelling a Task is throwing an exception
  9. How to check if Thread finished execution
  10. Proper way to Dispose of a BackGroundWorker
  11. Using string as a lock to do thread synchronization
  12. Why am I getting this error:”Cross-thread operation not valid: Control lbFolders accessed from a thread other than the thread it was created on.”?
  13. Raise Events in .NET on the main UI thread
  14. Can you link to a good example of using BackgroundWorker without placing it on a form as a component?
  15. Why CancellationToken is separate from CancellationTokenSource?
  16. How to correctly read an Interlocked.Increment’ed int field?
  17. Async WebApi Thread.CurrentCulture
  18. Is it safe to use a boolean flag to stop a thread from running in C#
  19. ConcurrentDictionary Pitfall – Are delegates factories from GetOrAdd and AddOrUpdate synchronized?
  20. Thread safety on readonly static field initialisation
  21. Synchronous implementation of interface that returns Task
  22. How to exit all running threads?
  23. Access to disposed closure in C#?
  24. Return a value from an Event — is there a Good Practice for this?
  25. Does Func.BeginInvoke use the ThreadPool?
  26. Update label from another thread [duplicate]
  27. SqlConnection Thread-Safe?
  28. Is it good idea to use “Control.CheckForIllegalCrossThreadCalls = false” [duplicate]
  29. .NET Core equivalent to Thread.Abort
  30. Memory usage in C#

Leave a Comment