On Fri, Apr 11, 2008 at 9:43 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Tue, 8 Apr 2008 14:02:50 -0300 "Gustavo Sverzut Barbieri" > <[EMAIL PROTECTED]> babbled: > > > > On Tue, Apr 8, 2008 at 11:05 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > This patch doesn't break anything at this time :-) It's a > > > standalone feature that just add the possibility to evas to receive > > > events from another thread. It introduce 3 new API. > > > > I'm not sure the fd must be set to non-block, this might cause more > > trouble than good. I'd make it blocker for now and handle things > > properly using select(), or believe that when the file descriptor is > > ready to read (from ecore_fd_main...) we can read everything (ie: no > > partial writes, no threads will die with incomplete writes). > > non-block is fine. that's what select() is for :) read the fd while there are > things to read - then stop and let select tell u more is there to read. this > fd > is to let evas wake up the calling program for an event that happened > asynchronously - so that's all we need. it really only needs to write 1 word > or > byte down the pipe as a signal. personally i'd write a void * (pointer) that > is > a pointer to a message (struct) of some sort. a standard one. it is the > reader's job to take the struct, pass it on to some handler and free it when > done. posting events is just a matter of waking the process up. you want to > do > this for example when an image has finished decoding (maybe if u want > progressive load u do it multiple times during load). this is very useful. :)
I also agree with just using pipe to wakeup, but I'd go with a byte. Problem is that if we read more data from a non-blocking fd, then we might end with partial reads, then we must keep this somewhere for future readings... THAT's a problem and that's painful to get right with non-blocking, if we don't take care, bugs may show and they would be hard to track. Bytes are "atomic" there, just read one byte, pop from the queue and process, then read another, pop, process... > > I'm not sure about evas_init() doing this. Nothing against it, but > > maybe some purist wouldn't like to have pthread mutexes created. > > i would make this optional. if u are never going to use async stuff - it > should > just do nothing. the fd should just never wake up, or what is done in a > thread > can be just done in-line and the wakeup can be emulated. make what optional, and where? Make it whole async stuff compile-time optional? -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
