#8532 NORM 8.2.0 (: SIGCHLD fights with threads.

[Zarro Boogs per Child]

#8532: SIGCHLD fights with threads.
--------------------+-------------------------------------------------------
 Reporter:  cscott  |         Owner:  marco                            
     Type:  defect  |        Status:  new                              
 Priority:  normal  |     Milestone:  8.2.0 (was Update.2)             
Component:  sugar   |       Version:  Development build as of this date
 Keywords:          |   Next_action:  never set                        
 Verified:  0       |     Blockedby:                                   
 Blocking:          |  
--------------------+-------------------------------------------------------
 There are issues using SIGCHLD handlers and threads at the same time in
 python.  See for example:
  * http://twistedmatrix.com/trac/ticket/733
  * http://planet.gentoo.org/developers/agaffney/2005/03/18/python_sucks
  * http://twistedmatrix.com/pipermail/twisted-python/2006-May/013115.html
  * http://mail.python.org/pipermail/python-list/2000-September/050971.html
  * http://mildopinions.wordpress.com/2008/05/31/python-and-parallel-
 programming/
  * http://markmail.org/message/mllbvkemgymvvjgx
  * http://www.python.org/search/hypermail/python-recent/0691.html

 The particular issue is with sugar-update-control, which uses threads, and
 sugar.activity.activityfactory, which installs a SIGCHLD handler.  When
 sugar-update-control invokes sugar.bundle.contentbundle.install(), it
 creates a subprocess for the zip(), and the SIGCHLD from that subprocess
 is delivered not to the thread which is expecting it, but to the main
 sugar process instead, and Strange Things happen.

 There are a number of possible solutions, including using the clone()
 option to prevent SIGCHLD from being sent, using the sigaction option to
 prevent the need to wait(), forcibly resetting the signal handler when
 sugar-update-control is running, etc.

 But the most straightforward solution is attached: just replace
 activityfactory's signal handler with gobject's standard spawn_async
 functionality, which already wraps the SIGCHLD wait() code into gobject's
 event loop.

 This code is only used when security is disabled, so it should be pretty
 harmless for most users.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8532>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system