On Fri, 11 Apr 2008 23:28:29 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> 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... no need to make it blocking :) look at ecore_con - hell look at emotion. it's all done with non-blocking. for emotion i used void *'s to write that point to he message. it works by handing the pointer to a msg struct from the slave thread to the main one - it's quite handy that way. it's also generic as i can pass anything along from a slave to a master thread - just point to it :) the difference between a byte and a void * won't really be anything worth talking about as u are unlikely to pass 1000's of them at a time - even if u do, kernel buffers are 128k by default - that's 32k messages on 32bit and 16k on 16bit that u can buffer before draining... that's a LOOOOOOOT. > > > 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? no - the async fd is there, but the operation is not done in a thread. the load is done syncronously at load time if async stuff is disabled. u just need to have infrastructure where u can set a callback to be executed "async" - it will be (and then message back the event fd with a message when it's done) *IF* async evas stuff is enabled (enable by default), *IF it's not enabled, the callback will be called at the time you start the async operation (i.e at the time u begin the load). t5his means the load call, so to speak, will block and be slow until the async callback finishes, if async is disabled, and if enabled, it won't block. in both situations your async fd will wake up with an event you process later :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
