Re: [E-devel] Advice needed - threads, pipes and bears oh my
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
[E-devel] debian package building
hi,
i was trying to build the Debian packages for efl and e,
but there are some errors in the control files, for example for
eina/debian/control
i made the following changes:
igor:~/e/trunk/eina# svn diff debian/control
Index: debian/control
===
--- debian/control (revision 54229)
+++ debian/control (working copy)
@@ -27,7 +27,7 @@
Package: libeina-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, libeina-svn-04 (= ${binary:Version}), pkg-config
+Depends: ${misc:Depends}, libeina (= ${binary:Version}), pkg-config
Recommends: libeina-doc
Description: Development files for libeina
Eina is a multi-platform library that provides optimized data types and a
few
@@ -67,7 +67,7 @@
Package: libeina-dbg
Architecture: any
Section: debug
-Depends: ${misc:Depends}, libeina-svn-04 (= ${binary:Version})
+Depends: ${misc:Depends}, libeina (= ${binary:Version})
Priority: extra
Description: debugging symbols for use with libeina
Eina is a multi-platform library that provides optimized data types and a
few
but i see problems in most of the debian control files, who is maintaining
them?
regards,
Maikel
--
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
Re: [E-devel] E SVN: discomfitor trunk/ecore/src/lib/ecore
On Sat, 6 Nov 2010, Enlightenment SVN wrote: Log: add ecore_con strings Author: discomfitor Date: 2010-11-06 10:06:56 -0700 (Sat, 06 Nov 2010) New Revision: 54241 Modified: trunk/ecore/src/lib/ecore/ecore.c I think that those strings should not go into ecore.c Vincent Modified: trunk/ecore/src/lib/ecore/ecore.c === --- trunk/ecore/src/lib/ecore/ecore.c 2010-11-06 17:04:09 UTC (rev 54240) +++ trunk/ecore/src/lib/ecore/ecore.c 2010-11-06 17:06:56 UTC (rev 54241) @@ -276,6 +276,15 @@ case ECORE_MAGIC_EVENT: return Ecore_Event (Event); break; + case ECORE_MAGIC_CON_SERVER: +return Ecore_Con_Server (Connection Server); +break; + case ECORE_MAGIC_CON_CLIENT: +return Ecore_Con_Client (Connection Client); +break; + case ECORE_MAGIC_CON_URL: +return Ecore_Con_Url (Connection Url); +break; default: return UNKNOWN; }; -- 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-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- 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
[E-devel] debian dirs in svn
Can these be deleted since they haven't been updated in a few years? -- 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
Re: [E-devel] debian dirs in svn
On Saturday, November 6, 2010, Mike Blumenkrantz m...@zentific.com wrote: Can these be deleted since they haven't been updated in a few years? +1, go for it. That should never be in each lub/app anyway. The correct way would be a packaging/debian, but the maintainers (albin at least) uses an external repo for it -- 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 -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] Advice needed - threads, pipes and bears oh my
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!
