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.
pgpXgnV0MKuQr.pgp
Description: PGP signature
