Chronological Thread 

< Chronological >      < Thread >

---

On Monday 22 May 2006 01:30,
rcl AT ihug.co.nz
wrote:
> Hi,
>
> There is a problem with ext_poll in socketapi-1.7.0.
>
> The use of the getdtablesize() function is incorrect.
>
> E.g., on my system, it is returning 256, which is less than
> the fake file descriptor values (around 1024) used by
> sctplib. Then of course ext_select ignores the FDs passed
> in.

The socket API uses a field of FD_SETSIZE entries. ext_select() always uses
this constant. May be, you are using a very old version of the socket API. I
think I have removed some getdtablesize() calls a long time ago.
Nevertheless, I fixed the allocation of socket API FDs starting from
getdtablesize()-1. This should solve eventual problems.


> A minimal patch to fix this is below, although I think it
> would be preferable to implement ext_poll directly, rather
> than going through ext_select.
>
> There are someother minor problems with ext_select and
> ext_poll (not fixed in my patch).
>
> 1. In ext_select, the logic for filling in the returned
> bitmasks appears to be done twice - you clear out the
> bitmasks, fill them, clear them out a second time and fill
> them in again.

No, the first step iterates the SCTP sockets (based on the Condition object
hierarchy); the second step interates the non-SCTP sockets (based on the
sctplib's user callback).


> 2. The return values from ext_poll and ext_select are not
> quite correct.
>
> A successfull call to ext_poll is meant to return the number
> of pollfd.revent fields filled in with non-zero values.
> Currently it just returns what ext_select returns.
>
> A successfull call to ext_select is meant to return the
> total number of bits set in the FDs on return. This does
> not appear to be calculated correctly.

I will fix this problem.


> 3. For the case where the FD sets are empty, the return
> value is not correct. You fall back to doing:
>
> select(0,NULL,NULL,NULL,timeout);
>
> but ignore the return value (which may be -1, EINTR).

I will fix this problem.


> 4. I think the getErrnoResult function used in the
> errno_return macro, is not correct in the success case. It
> sets errno=0. The Unix logic is to not change errno on
> success, I believe.

I think it is not incorrect to set errno to 0, but it is clearly not
necessary. Therefore, I will remove this code.


> PS. Is there a cvs (or other version control) of sctplib
> and socketapi available?

I will provide you a tarball of the latest version after I have fixed the
problems. We will also release a new version quite soon, since I have fixed
various problems in sctplib and socketapi since the last release.


Best regards
--
=======================================================================
Dipl.-Inform. Thomas Dreibholz

University of Essen, Room ES210
Inst. for Experimental Mathematics Ellernstraße 29
Computer Networking Technology Group D-45326 Essen/Germany
-----------------------------------------------------------------------
E-Mail:
dreibh AT exp-math.uni-essen.de
Homepage: http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

Attachment: pgpUyn6lfGHhu.pgp
Description: PGP signature

---

• [SCTP-Discussion] ext_poll problem, rcl, 05/22/2006
  • Re: [SCTP-Discussion] ext_poll problem, Michael Tuexen, 05/22/2006
  • Re: [SCTP-Discussion] ext_poll problem, Thomas Dreibholz, 05/23/2006
  • <Possible follow-up(s)>
  • Re: [SCTP-Discussion] ext_poll problem, rcl, 05/22/2006
    • Re: [SCTP-Discussion] ext_poll problem, Michael Tuexen, 05/22/2006

---

Archive powered by MHonArc 2.6.19+.