On Fri, 5 Nov 2010 23:49:43 -0400 Jesse Charbneau <j...@thecharbneaus.com> wrote:
> Hello All, > I am working on a project in which I am running into some difficulties. To > provide a brief overview, I have a device that I connect to via RS232 (using > termios) and read in a 16 character hex string. This hex string is a locator > of sorts in that it will tell me what hardware based devices have been > attached to it. From there, I take the character string, convert it, and > this tells me what I need to enable in the touchscreen interface (using edje > mainly). My first inclination was to use ecore_ipc as I’ve used it to great > success in the past, but ran into issues there ( I tried both a timer with a > call to just read the line data, and also tried a while). The while loop of > course did not work as I needed the ecore main loop in order to get my IPC > functionality going (am I wrong here, is there a better way to approach). > This also created timing issues when trying a simple if(fgets.....) as the > device sends me a stream every .5 seconds (which will eventually be tuned to > be a minimum of 1/10th of a second). After much fuss (even tried using > fifo’s a bit), I settled on using a single process with a fork/pipe approach, > but I’ve noticed some performance issues there. I’ve read around on the net > lots, and am not entirely comfortable with threads (I’ve heard much bad juju > re: threads), but that seems performance wise much better than fork (from my > own testing as well as tables on the net stating similar). The other piece > of the fork problem is that while I can spawn off a separate child to perform > the serial i/o work, I still have to get the data back to the main process so > have a standard pipe that I have attached a timer to. I’m sure I’m missing > something here, but for the life of me can’t think myself out of this one. > > As a research exercise, I’ve been tooling around with pthreads, and it seems > like I can spawn a thread that will do my serial work just fine, and have > tested both running 1 thread to perform serial work, with 1 thread running > ecore based code, but that bombed (I did see the notice regarding EFL not > being thread safe, but figured I’d try it out just the same ;-) . Running a > parent that spawned a thread for just the serial work and then continue on to > interface code seemed to work ok, but not sure if this is correct or not. I > also found the following link suggesting that threads can be used, but you > have to marshall back to the main loop. That is kind of greek to me, so am > hoping some one can review the above and tell me if I’m marching in the right > direction, and how to “marshall” back to the main thread? Also, I noticed > reference to Ecore_Thread, but am not familiar with it and find little > documentation for that library. Can someone suggest some code I can review > that makes use of this functionality? > > Here is the link regarding some notes to the effect of Ecore_Thread, EFL > thread safety: http://trac.enlightenment.org/e/wiki/EFLOverview > > The quote that got me thinking: > "Ecore_Thread is a way to divide the work between heavy function that will > run in another process and some callback that will be from the mainloop. > Making thread use easy with the EFL. If you must spread your work across > multiple CPU's for performance, then divide and conquer. split it up into > many worker threads that do the bulk of the work without EFL and then marshal > back results to the mainloop to update the application state (and GUI) > accordingly.” > > I also noticed one of the developers introduced Ecore_Pipe, but have seen > very little about it, other than the post to the mailing list. Is that a > viable alternative for me? > > Thanks everyone! > Jess http://docs.enlightenment.org/auto/ecore/ http://docs.enlightenment.org/auto/ecore/group__Ecore__Thread__Group.html http://docs.enlightenment.org/auto/ecore/group__Ecore__Pipe__Group.html -- Mike Blumenkrantz Zentific: Our boolean values are huge. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
