On Sun, 13 Apr 2008 13:35:58 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> On Sat, Apr 12, 2008 at 2:37 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > no need to make it blocking :) look at ecore_con - hell look at emotion. > > it's > > Well, I looked at emotion and damn, it's wrong! :-P > > Ok, it will work for most of the cases where you are within the buffer > size, but then it would also not block if you're in the same situation > and have not set the non-blocking flag. > > The problem is at the border condition: full buffer: > - blocking would block the call and make the sender process (in this > case, the thread) to block a while... IMO this is not so bad, as the > main process is not being capable of reading it at all. > - non-blocking would write partial and stay looping to write the > remaining bytes... so blocking the same way, or it would do a partial > write if you don't loop. Also, on the read side, depending on the > implementation it would either loop (so blocking) waiting for data or > do partial reads (as it might do with Emotion), these partial reads > are the damn bug-causing I'm talking about. > > read() and write() does not do all the work for us because these are > really low level functions enabling us to do such a looping solution > (that blocks in any way) or queueing the data elsewhere (todo-buffers) > and doing something else if the read/write fails... but doing these > todo-buffers is really a PITA, I never see nobody using them, maybe > these are used in some high-performance servers that can keep > todo-buffers for each socket and try to dispatch other sockets if some > are blocked. > > > Just read emotion code and consider: > - Thread 1: write 3xmessage-size bytes (consider message-size being > 2 bytes: [AA|BB|CC]) where? it writes void * sized messages. the vo_out plugin writes only 1 void * msg, the slave writes 2 * void *, the event thread writes 2 * void *. no 3x there? > - Thread 2: read message-size bytes [AA], then read 1 byte [B]... > it's not of message-size bytes, then discard (!!!) and try to read > message-size bytes again, which you can do because you still have 3 > bytes there, so you end with [BC], then you process this wrong pointer > and then read message-size again, being unable because just [C] is > there. hmm in practice this won't happen. thread 1 has written a full message into the fd - it's all available, or should be. :) as kernel buffers are 64k or 148k - but are always a page size multiple in reality, you will always have a whole number of messages in the buffer :) > I don't even want to read ecore_con! If it resemble emotion then it's > wrong and it might incur in security risk for all code using it... The > risky is not that important since you don't handle pointers to a > process to another, just between threads, and nobody would replace a > thread... :-P ecore_con knows nothing of message sizes. it just reads as many bytes as it can and puts them into a buffer together then hands it off to the rest of the app as an event. > What also makes me wonder: why not make this kind of thing available > in ecore? Just handle read/write file descriptors to a function to > have these configured (maybe also set the buffer size based on message > size) and provide ecore_read() and ecore_write() with these loops all > handled? This is way better than spreading these weird loops all over > the code, many can be just wrong and will spread bugs :-/ that is what the talk of ecore_pipe was about. it would set up these pipes, fd handlers etc. and handle putting messages on the pipe queue and gettting them off and presenting them as events - much like ecore_con. > > 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 guess you mean 16K on 64bit... :-) yeah! that's what i meant :) > Ok, your example fits into the buffer size exactly, but we shouldn't > trust this to be always true. Also, as I tried to show, the blocking > code would just do the same thing and make the error-handling easier. i know it does :) that's why i did it :) but yes - block on WRITE would be good. blocking read is what i was thinking - u don't want to block :) > -- > Gustavo Sverzut Barbieri > http://profusion.mobi > Embedded Systems > -------------------------------------- > MSN: [EMAIL PROTECTED] > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- ------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
