On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: > while i have nothing against adding locks on primitives - if we do it in one > place (ecore) we will need to start doing it everywhere. locks will add > overhead. those on limited computing (embedded devices) will feel it most. > also > if we look at the work needed to add it everywhere - that's not a small > undertaking at all. i have decided in the past not to bother as gustavo put > this clearly - i kind of expect people to have threads do entirely independent > things outside the main gui thread and communicate back cleanly via pipes - > glib expects people to use threads with glib and has primitives for making > them > interact directly with the main loop from a thread. different design > approaches > there. > > right now i (personally) thing the best way to integrate is to have ecore main > loop and glib main loop run in separate threads, with them communicating via > pipes used to glue them together. maybe some pipe wrapping/handling stuff in > ecore might help with this? >
That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
