#2654 HIGH Trial-3: Sugar Shell is offering D-Bus services in the UI loop

[Zarro Boogs per Child]

#2654: Sugar Shell is offering D-Bus services in the UI loop
---------------------+------------------------------------------------------
  Reporter:  tomeu   |       Owner:  tomeu  
      Type:  defect  |      Status:  new    
  Priority:  high    |   Milestone:  Trial-3
 Component:  sugar   |     Version:         
Resolution:          |    Keywords:         
  Verified:  0       |  
---------------------+------------------------------------------------------
Comment (by tomeu):

 Replying to [comment:5 AlbertCahalan]:
 > Replying to [comment:4 tomeu]:
 >
 > > Well, all services offered today by the Shell are fast enough. But
 this could change some day. Any service that uses the network is
 potentially very slow and shouldn't be called synchronously by an UI
 thread or by another D-Bus service.
 >
 > Slow network things are perfectly OK to do from the UI loop. You set the
 network file descriptor to non-blocking, then use poll() or select() to
 see when you can read/write without blocking.

 Sure, we'll do async all operations that are not guaranteed to be almost
 instantaneous from the user POV.

 > > But anyway, the real problem here are dead locks. Having the same
 process/thread/eventloop doing the UI and at the same time providing
 generic services to activities and other services is going to cause dead
 locks.
 >
 > Sure you have a real deadlock? That tends to be more common when using
 threads. Merely blocking (waiting for a network connection for example) is
 cleanly solvable with non-blocking IO.

 Well, we have many situations like the following:

  1. a text snippet is dropped into the frame.
  2. the shell asks the clipboard service to add a new clipboard object
  3. the clipboard service asks the shell service which activities support
 opening that mime type.
  4. the shell service cannot answer because the UI thread is blocking on 2
 -> deadlock

 We have timeouts in dbus operations, so the deadlock is temporary.

 Of course we could do all operations async, but this will make the code
 much, much more complex. In my opinion, we have a wrong architecture that
 needs to be rethought.

-- 
Ticket URL: <https://dev.laptop.org/ticket/2654#comment:7>
One Laptop Per Child <http://laptop.org/>