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]) - 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. 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 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 :-/ > 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... :-) 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. -- 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
