* [sup-devel] Strategy for dealing with nil and thread errors
@ 2011-01-20 22:57 Edward Z. Yang
2011-01-21 6:46 ` Rich Lane
2011-01-21 6:59 ` Tero Tilus
0 siblings, 2 replies; 3+ messages in thread
From: Edward Z. Yang @ 2011-01-20 22:57 UTC (permalink / raw)
To: sup-devel
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
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [sup-devel] Strategy for dealing with nil and thread errors
2011-01-20 22:57 [sup-devel] Strategy for dealing with nil and thread errors Edward Z. Yang
@ 2011-01-21 6:46 ` Rich Lane
2011-01-21 6:59 ` Tero Tilus
1 sibling, 0 replies; 3+ messages in thread
From: Rich Lane @ 2011-01-21 6:46 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: sup-devel
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
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [sup-devel] Strategy for dealing with nil and thread errors
2011-01-20 22:57 [sup-devel] Strategy for dealing with nil and thread errors Edward Z. Yang
2011-01-21 6:46 ` Rich Lane
@ 2011-01-21 6:59 ` Tero Tilus
1 sibling, 0 replies; 3+ messages in thread
From: Tero Tilus @ 2011-01-21 6:59 UTC (permalink / raw)
To: sup-devel
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
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-01-21 8:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-20 22:57 [sup-devel] Strategy for dealing with nil and thread errors Edward Z. Yang
2011-01-21 6:46 ` Rich Lane
2011-01-21 6:59 ` Tero Tilus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox