Openmoko Bug #1549: [exposure] want to launch exposure again while it is in the e-illume bar, need 5~10 sec

Openmoko Public Trac bugs at docs.openmoko.org
Fri Jul 25 15:19:04 CEST 2008


#1549: [exposure] want to launch exposure again while it is in the e-illume bar,
need 5~10 sec
--------------------------+-------------------------------------------------
 Reporter:  wendy_hung    |        Owner:  marek   
     Type:  defect        |       Status:  assigned
 Priority:  normal        |    Milestone:  ASU     
Component:  E - Illume    |      Version:          
 Severity:  normal        |   Resolution:          
 Keywords:  must have pm  |     Blocking:          
Blockedby:                |  
--------------------------+-------------------------------------------------

Comment(by raster):

 1) i just changed the sensitivity... look at asu dev images built these
 days... have to wait for holger to propagate to stable.
 2) the problem again is python (bindings). if u kept an ecore main loop
 running then you could use the Signal_User event and do it all cleanly...
 and in c it's trivial, as above, but python, i believe doesnt wrap these.
 thus blocks their use from you (until wrapped). they were put in there for
 this kind of usage scenario - if you want to use simple system signals for
 some form of ipc. as such i use this in several places myself - in e17 i
 use it for the init splash to synchronize startup, sigchilds are handled
 all the time for exiting subprocesses (and converted to events with the
 whole waitpid() thing done for you collecting exit code and other
 information all nicely delivered in an event). e17 also uses sighup as a
 restart and re-loadconfig signal... so it all works... but it works
 because it uses the constructs created for just this (to make it reliable
 and simple without "gotchas" of normal signal handlers). :( python is
 being your problem - or more specifically the bindings and the fact they
 are a subset. so as such signalling via sigusr1/2 will work just fine...
 IF you use the constructs designed to streamline this into the main loop.
 because you set your own signal handler - you removed that feature
 basically (which you couldn't use anyway as the bindings don't support
 it)...

 now... choices are:

 1. add more to the python bindings to allow use of these events:
 or
 2. try another mechanism that the bindings already support.

 with #2 - you have fd_handlers.. you could create a pipe (named pipe
 somewhere - not unix socket) and then st up an fd handler to listen for a
 read on it - write to it to wake it up, on any data being written just
 activate...

 look for fd_handler_add in the ecore  bindings...

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/1549#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list