On Fri, 16 Dec 2005 08:07:03 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> While I was investigating the best way to go about adding line > buffering to ecore_exe, I stumbled upon a little problem. The return > value from fd handlers is not documented anywhere, and it is in fact > used differently under different circumstances. > > If there is a buf_func defined for this handler, then a return of non > zero more or less means "there is more to do, keep calling all handlers > with a buf_func in a tight loop". The tight loop allows exiting from the > loop if buf_func or the handler returns zero. > > If there is no buf_func defined, then returning zero means "delete this > fd handler". The Ecore_Fd_Handler structure has a delete_me member > that means "delete this fd handler". There is also an > ecore_main_fd_handler_del() function. > > At the moment only ecore_x defines a buf_func for it's fd_handler. > It's handler always returns one, so there is no chance for it to > accidentally get deleted. It's buf_func returns zero sometimes, thus > exiting from the tight loop. > > I have not untangled the logic enough yet to see if returning zero from > your fd handler can cause accidental deletion if used with a buf_func. > Since none of this behaviour is documented, someone is likely to do > that one day, and it will likely drive them crazy trying to figure out > why their fd handler suddenly stops working. > > Since there are other ways to delete your fd handler, I suggest that we > don't delete it on the return of zero from the handler, and document > that returning zero means "there is more to do, call me back soon > without bothering with a select()". On the other hand, some users of > fd handlers may be relying on the delete on zero return behaviour, I > haven't checked them all yet. If we go ahead with this, these will > need to be changed to do an explicit delete using the del function. i think this is a mater of documentation, not chaning api. basically i did it that way because some (very rare) systems like xlib do their own buffering and may read data at any time and thus select will say there is no data to read, but there really is, in internal xlib buffers. i was very annoyed at havng to do that - but xlib forced it. the kind of reads are very different - thus why they return different values :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
