Hello, Thanks Cedric (and MIke too!). I’ve been testing out ecore_thread_feedback_run and have been able to get func_notify to work, but am struggling a bit on getting the data out. I’ve looked over the source and don’t see where any apps are using this functionality, so am lacking some example to learn from . Any direction would be helpful. In the meantime, I’ll keep banging on it until something gives ;-). Side note, moving the serial read i/o over to using ecore_thread_feedback_run I already see improvements in the animations with-in edje, so I think this is going to work, just have to school myself enough to understand the data portion :-).
Thanks again guys! Jess On Nov 6, 2010, at 7:38 AM, Cedric BAIL wrote: > On Sat, Nov 6, 2010 at 4:49 AM, 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? > > Look at ecore_thread_feedback_run, ecore_thread_feedback, > ecore_thread_cancel and ecore_thread_check. > -- > Cedric BAIL ------------------------------------------------------------------------------ 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
