>>> On 9/6/2007 at 12:22 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> On 8/24/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>
>> I haven't looked at this code yet, but it sounds like something that should
> be using the APR API's rather than native API's. That should solve the
> problem without having to do any kind of platform special stuff.
>
> I plan to apply Mike's patch to branch-3.0.x -- do you think you can
> fix this in trunk using the Apr API?
>
> Thanks,
>
> Bernard
After taking a closer look at the apr_poll implementations, I don't see
anything in APR that specifically addresses the problem with platform
differences of POLLHUP. The apr_poll implementation is mostly dealing with a
set of apr_poll functions that will work on all platforms regardless whether
the platfom supports poll, epoll or just select. So I am going to make the
assumption for now that moving this code in gmetad to apr_poll will not solve
the POLLHUP issue.
In light of that assumption and the fact that gmetad is not really built on
APR, moving the poll code to APR would obviously not be worth the effort, not
solve an identified issue and risk destabilizing gmetad unnecessarily. I do
believe that gmetad should be moved on top of APR as well as making sure that
all of the infrastructure code used by gmond uses APR fully as well. However,
for now this task fits into the "nice to have" category rather than actually
solving a real issue. So I would suggest that we just apply the same 3.0.5
POLLHUP patch to trunk and call it good for now.
But I do have one question regarding the 3.0.5 POLLHUP patch. It looks like
the real problem with the code is that on an EOF, POLLIN and POLLHUP are
actually received together. Therefore, the code in data_thread.c would go
ahead and read the recv buffer and the proceed to throw everything away in the
following "if" statement that checks for POLLHUP. If this is the case, then
would the following patch work better for all platforms without having to
#ifdef the code as well as still allowing POLLHUP to stand on it own? (BTW,
this patch is against trunk, not 3.0.5)
Index: data_thread.c
===================================================================
--- data_thread.c (revision 829)
+++ data_thread.c (working copy)
@@ -130,6 +130,10 @@
break;
}
read_index+= bytes_read;
+ if( struct_poll.revents & POLLHUP )
+ {
+ break;
+ }
}
if( struct_poll.revents & POLLHUP )
{
This patch would just detect the EOF condition signaled by POLLIN | POLLHUP and
allow the data buffer to process the data normally in the same way as if
bytes_read == 0.
Brad
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
