Re: [MiNT] tcp_select / sys_f_select

[m0n0 <ole@monochrom.net>]

Hello to the list,

> It seems like the poll is returning to early, it returns when the
> socket is ready to be used for sending data ( from FreeMiNTs point of
> view) - but it is still not ready for reading, the recv() call is
> ending up with the ENOTCON error... but previous send() did not return
> that error!

OK, I found the problem. the whole thing can be fixed within tcp_ioctl
( I prefer that, because users don't have to update the kernel).
But probably it can also be fixed within sys_f_select, if it's OK to
change it's behavior. 

I'm writing all the things I found, although not everything is needed
to fix the problem:

1. sys_f_select looks for data even if device->select returned 0 
   is this correct behavior? This possible can be changed
   when the second (or was it the third?) for loop uses col_wfd,
col_rfd, col_xfd 
   instead of wfd,rfd... 
   wfd, rfd etc. contain the original descriptors that the user passed
to sys_f_select, col_wfd, etc contain 
   the descriptors which returned 1 during device->select. 

2. tcp_ioctl FIONWRITE returns space = UNLIMITED as default... is this
OK? wouldn't it be better to return 0 as default? 
   Anyway, for my situation it would be enough if states TCBS_SYNSENT,
TCBS_SYNRCVD return 0. 
   But then I would have to clear the socket error within curl before
calling poll, 
    because data->err is set and that also results in space =
UNLIMITED. (And because sys _f_select doesn't bother if 
   tcp_select returned 0, this means the socket is writable).

3. no need to change curl or sys_f_select when tcp_ioctl is altered
that way that it returns 0
   for the states TCBS_SYNSENT, TCBS_SYNRCVD AND if data->err == true. 

How would you decide? :)

Greets,
m