Development Team/Almanac: Difference between revisions

Line 202:

=== My Python activity wants to use threads; how do I do that? ===

~~Early versions of Sugar (pre-"Update.1" release) would automatically configure Python, gobject, and glib~~ for ~~threaded operation. Due to the overhead imposed on every activity by those initializations,~~ Sugar ~~no longer does that~~. ~~If you are writing an activity for a later release, and you want threads~~ to work~~, start off your activity (just after the copyright comments) with~~:

A question that has been answered with limited success is which threading patterns are most appropriate for use in Sugar. The following pattern of code to work fine in basic instances:

~~import os~~

<pre>

~~import logging~~

#### Method: __init__, initialize this AnnotateActivity instance

def __init__(self, handle):

~~# Sugar does this but only in pre-update~~.1.

...

~~import gobject~~

self.sample_thread = Thread(target=self.announce_thread, args=())

~~gobject~~.~~threads_init~~()

self.sample_thread.setDaemon(0)

~~#import dbus~~.~~mainloop~~.~~glib~~

self.sample_thread.start()

~~#dbus~~.~~mainloop~~.~~glib~~.~~threads_init()~~

...

~~Comment out, or uncomment, the glib threads initialization, depending on whether you need it~~. (~~I don't know how to tell if you need it~~, ~~except by trying it both ways.~~)

def announce_thread(self):

while (self.Running):

time.sleep(1)

print "thread running"

self._update_chat_text("Thread", "In here")

</pre>

~~Then follow~~ that with the ~~rest of your imports (such as "import gtk"). In my~~ activity ~~(SimCity), the pygame sound player would not produce sound reliably unless I did this.~~

This is the basic series of steps that most online documentation on python suggests to use when trying to work with threads in python. The problem is that it is unclear how this pattern relates to code that worked in the SimCity activity:

~~In SimCity, I have tested this to make sure it works in the *old* XO software releases as well as the new ones~~. ~~The documentation for these~~ threads_init ~~functions is really bad, and doesn't say whether you can call them twice, nor does it say how you can tell if they've already been called so you could avoid calling them twice~~. ~~Apparently it's pretty harmless in release 650~~.

<pre>

import gobject

gobject.threads_init()

#import dbus.mainloop.glib

#dbus.mainloop.glib.threads_init()

</pre>

It should be noted that in the SimCity activity the pygame sound player would not produce sound reliably unless this setup was done.

<p/>

Should the two patterns always be used in tandem? It seems that the latter code is mainly to initiate gobject and other libraries to work with threading, but it is unclear what restrictions there are with using threading with these libraries. Does one take precedence over the other? It is not clear if there is any problem with using the standard python threading code on the sugar technology stack.

<p/>

In fact, experiments with threading on sugar leads to several different problems. For one thing, thread termination was tricky - using the can_close() method for sugar activities to terminate an activity only killed threads in some circumstances. It did not properly handle terminating threads in the case of CTRL-C or terminal interrupts. You can try to catch signals (SIGINT, SIGTERM or SIGHUP), but you will still be running in to errors in terminating child threads using these as well.

<p/>

Another set of errors with threading comes up when trying to combine with stream tubes. The bottom line is that it is unclear what the scope of threading in a Sugar activity should be - should it simply work if you do the standard python threading pattern, is the use of the glib.threads_init and gobject.threads_init calls necessary, are there other interactions with threads and dbus that need to be accounted for? With more clarity from sugar developers on how the platform envisions threading to work in an activity, we can be more comfortable writing entries in the Almanac to help developers write error-free code.

=== How do I customize the title that is displayed for each instance of my activity? ===

@@ Line 202: / Line 202: @@
 === My Python activity wants to use threads; how do I do that? ===
-Early versions of Sugar (pre-"Update.1" release) would automatically configure Python, gobject, and glib for threaded operation.  Due to the overhead imposed on every activity by those initializations, Sugar no longer does that.  If you are writing an activity for a later release, and you want threads to work, start off your activity (just after the copyright comments) with:
+A question that has been answered with limited success is which threading patterns are most appropriate for use in Sugar.  The following pattern of code to work fine in basic instances:
- import os
+<pre>
- import logging
+  #### Method: __init__, initialize this AnnotateActivity instance
+    def __init__(self, handle):
- # Sugar does this but only in pre-update.1.
+        ...
- import gobject
+        self.sample_thread = Thread(target=self.announce_thread, args=())
- gobject.threads_init()
+        self.sample_thread.setDaemon(0)
- #import dbus.mainloop.glib
+        self.sample_thread.start()
- #dbus.mainloop.glib.threads_init()
+        ...
-Comment out, or uncomment, the glib threads initialization, depending on whether you need it.  (I don't know how to tell if you need it, except by trying it both ways.)
+    def announce_thread(self):
+        while (self.Running):
+            time.sleep(1)
+            print "thread running"
+            self._update_chat_text("Thread", "In here")
+</pre>
-Then follow that with the rest of your imports (such as "import gtk").  In my activity (SimCity), the pygame sound player would not produce sound reliably unless I did this.
+This is the basic series of steps that most online documentation on python suggests to use when trying to work with threads in python. The problem is that it is unclear how this pattern relates to code that worked in the SimCity activity:
-In SimCity, I have tested this to make sure it works in the *old* XO software releases as well as the new ones.  The documentation for these threads_init functions is really bad, and doesn't say whether you can call them twice, nor does it say how you can tell if they've already been called so you could avoid calling them twice.  Apparently it's pretty harmless in release 650.
+<pre>
+import gobject
+gobject.threads_init()
+#import dbus.mainloop.glib
+#dbus.mainloop.glib.threads_init()
+</pre>
+It should be noted that in the SimCity activity the pygame sound player would not produce sound reliably unless this setup was done.
+<p/>
+Should the two patterns always be used in tandem? It seems that the latter code is mainly to initiate gobject and other libraries to work with threading, but it is unclear what restrictions there are with using threading with these libraries. Does one take precedence over the other? It is not clear if there is any problem with using the standard python threading code on the sugar technology stack.
+<p/>
+In fact, experiments with threading on sugar leads to several different problems. For one thing, thread termination was tricky - using the can_close() method for sugar activities to terminate an activity only killed threads in some circumstances. It did not properly handle terminating threads in the case of CTRL-C or terminal interrupts. You can try to catch signals (SIGINT, SIGTERM or SIGHUP), but you will still be running in to errors in terminating child threads using these as well.
+<p/>
+Another set of errors with threading comes up when trying to combine with stream tubes. The bottom line is that it is unclear what the scope of threading in a Sugar activity should be - should it simply work if you do the standard python threading pattern, is the use of the glib.threads_init and gobject.threads_init calls necessary, are there other interactions with threads and dbus that need to be accounted for? With more clarity from sugar developers on how the platform envisions threading to work in an activity, we can be more comfortable writing entries in the Almanac to help developers write error-free code.
 === How do I customize the title that is displayed for each instance of my activity? ===