[PATCH] testpoll fix for Solaris port backend [was: Re: Showstoppers to apr release(?)]

[Henry Jen <he...@ztune.net>]

Hi,

Attached is a patch fix the testpoll issues found on Solaris. It
combines the previous fix for removing a poll.

This patch basically minimize the timing window to make a
port_associate before someone is trying to retrieve events from the
port.

Cheers,
Henry


On 10/30/07, Henry Jen <he...@ztune.net> wrote:
> On 10/30/07, Henry Jen <he...@ztune.net> wrote:
> > On 10/29/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > > William A. Rowe, Jr. wrote:
> > >
> > > > * Solaris 10, testpoll.c:314 we are failing with only APR_POLLOUT when we
> > > >   had expected both APR_POLLIN and APR_POLLOUT to be signaled.  Ideas?
> > >
> >
> > Seems like an issue with event port library, to associate with both
> > POLLIN and POLLOUT event does not work on Solaris. I had created a
> > simple test program as attached, and I noted that if we change the
> > associate to POLLIN only, we will get the POLLIN event.
> >
> > Disable detection of port_create from configure.in to force using poll
> > on Solaris pass the test.
> >
> > I am forwarding this to OpenSolaris developers and hopefully will get
> > some explanation.
> >
> >
>
> After some more investigation and read into the man page more carefully,
> I found the following explains the issue. The following discussion is
> based on the test code attached with previous email.
>
> Quoted from the man page of port_associate:
>
> > > Objects of type PORT_SOURCE_FD  are  file  descriptors.  The
> > > event  types  for  PORT_SOURCE_FD  objects  are described in
> > > poll(2).  At most one event notification will  be  generated
> > > per  associated  file  descriptor.   For  example, if a file
> > > descriptor is associated with  a  port  for  the  POLLRDNORM
> > > event  and  data  is available on the file descriptor at the
> > > time the port_associate() function is called,  an  event  is
> > > immediately  sent to the port.
>
> This explains the first event only has POLLOUT flagged, as sendto is
> called after port_associate. By switching the order, we get an event
> with POLLIN and POLLOUT both flagged.
>
> > > If data is not yet available,
> > > one event is sent to the port when data first becomes avail-
> > > able.
> > >
> > > When an event for a PORT_SOURCE_FD object is retrieved,  the
> > > object  no  longer  has  an  association with the port.  The
> > > event can be processed without the possibility that  another
> > > thread  can retrieve a subsequent event for the same object.
> > > After processing of the file descriptor  is  completed,  the
> > > port_associate()  function  can be called to reassociate the
> > > object with the port.
>
> This indicates another call to port_associate is needed within the while
> loop to continue receive events interested. By adding port_associate
> into the while loop, the program will get the POLLIN event at the second
> attempt without changing the order of sendto call as mentioned above.
>
> So a hack to fix to testpoll.c is to call apr_pollset_add after send_msg.
>
> A better fix for Solaris, IMHO, is don't call port_associate in
> apr_pollset_add but leave it to apr_pollset_poll by putting the
> request into the add_ring. Attached patch fix get over this issue.
> However, testpoll still have other existing failures on my Solaris
> Developer Express system.
>
> testpoll            : |Line 343: expected <0>, but saw <70015>
> |Line 523: expected <0>, but saw <70015>
> |Line 615: expected <0>, but saw <70015>
> FAILED 3 of 19
> Failed Tests            Total   Fail    Failed %
> ===================================================
> testpoll                   19      3     15.79%
>
> HTH,
> Henry
>
>