From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.42.229.71 with SMTP id jh7cs230642icb; Thu, 20 Jan 2011 23:30:14 -0800 (PST) Received: by 10.229.251.137 with SMTP id ms9mr292059qcb.188.1295595013900; Thu, 20 Jan 2011 23:30:13 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id c18si19035676qcr.104.2011.01.20.23.30.13; Thu, 20 Jan 2011 23:30:13 -0800 (PST) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 405EF185835A; Fri, 21 Jan 2011 02:30:13 -0500 (EST) Received: from pion.club.cc.cmu.edu (PION.CLUB.CC.CMU.EDU [128.237.157.88]) by rubyforge.org (Postfix) with ESMTP id B694718583C1 for ; Fri, 21 Jan 2011 01:40:59 -0500 (EST) Received: from rlane by pion.club.cc.cmu.edu with local (Exim 4.69) (envelope-from ) id 1PgAlq-00073G-0N; Fri, 21 Jan 2011 01:46:54 -0500 From: Rich Lane To: Edward Z. Yang In-reply-to: <1295563880-sup-5855@ezyang> References: <1295563880-sup-5855@ezyang> Date: Fri, 21 Jan 2011 01:46:53 -0500 Message-Id: <1295572751-sup-2112@zyrg.net> User-Agent: Sup/git Cc: sup-devel Subject: Re: [sup-devel] Strategy for dealing with nil and thread errors X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org 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