Subject: [sup-devel] Strategy for dealing with nil and thread errors

From: "Edward Z. Yang" <[email-masked]>
Date: Thu, 20 Jan 2011 17:57:22 -0500

My experience for having run Sup for some appreciable amount of time includes
running into a few Sup exceptions where 'the wrong id is called on some object'
or we attempt to access a field that doesn't exist on nil.  I also have run
into any number of race condition style bugs with respect to threading and the
user interface.

Usually the bugs are kind of harmless, so I just shrug, ignore the UI oddity,
reboot our client, and hope it doesn't come back again.  Sometimes it's really
bad, in which case I might need to reload our index (but usually it goes away
after that) or patch the immediate bit of code that is complaining and hope
I have encouraged some silent corruption.

I was curious if other people have had similar experiences.  I know threading
is fucking hard, and writing code that is robust against internal corruption
(which I assume is the source of nils) is fucking hard, but I think it's a worthy
goal and I think we should be thinking about ways to help rule out these errors
in the Sup codebase.

Cheers,
Edward
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel

---

From: Tero Tilus <[email-masked]>
Date: Fri, 21 Jan 2011 08:59:16 +0200

Edward Z. Yang, 2011-01-21 00:57:
> Usually the bugs are kind of harmless, so I just shrug, ignore the
> UI oddity, reboot our client, and hope it doesn't come back again.

Do you report the bugs you encounter?

> Sometimes it's really bad, in which case I might need to reload our
> index (but usually it goes away after that) or patch the immediate
> bit of code

Do you send in your patches?

> I was curious if other people have had similar experiences.

Not anymore.  For about a year now I've only managed to make sup spit
backtraces only from code I've written myself.

> I know threading is fucking hard, and writing code that is robust
> against internal corruption (which I assume is the source of nils)
> is fucking hard, but I think it's a worthy goal

Is there anyone who doesn't?

> and I think we should be thinking about ways to help rule out these
> errors in the Sup codebase.

Do you have any suggestions?  Besides the obvious "just try hard!"
which I assume all sup contributors already do.

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel

---

From: Rich Lane <[email-masked]>
Date: Fri, 21 Jan 2011 01:46:53 -0500

I think the UI should be single-threaded and event-driven. Index and
source operations should still be run in separate threads or processes
to avoid freezing the UI, but they should not be sharing any mutable
state.

This is a lot of work. If anyone is interested in tackling this I
suggest first discovering all the threads Sup uses and which of their
codepaths call into the UI or modify shared datastructures (Message,
Thread, ThreadSet, ...). Then that racy code needs to be moved to a
callback that runs in the event loop.

Some other robustness thoughts I've had:
- Immutable messages / different classes for messages constructed from
	source vs index
- Catch and log exceptions from keybindings
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel