> From: Bastien ROUCARIES [mailto:roucaries.bast...@gmail.com]
> Sent: Wednesday, September 05, 2012 1:55 PM
> To: Joachim Schmitz
> Cc: Junio C Hamano; Paolo Bonzini; bug-gnulib@gnu.org; g...@vger.kernel.org; 
> Erik Faye-Lund
> Subject: Re: poll() emulation in git
> 
> On Wed, Sep 5, 2012 at 1:24 PM, Joachim Schmitz <j...@schmitz-digital.de> 
> wrote:
> >> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> >> Sent: Tuesday, September 04, 2012 1:49 PM
> >> To: 'Junio C Hamano'
> >> Cc: 'g...@vger.kernel.org'; 'Erik Faye-Lund'
> >> Subject: RE: [PATCH v2] Support non-WIN32 system lacking poll() while 
> >> keeping the WIN32 part intact
> >>
> >> > From: Junio C Hamano [mailto:gits...@pobox.com]
> >> > Sent: Friday, August 24, 2012 9:47 PM
> >> > To: Joachim Schmitz
> >> > Cc: g...@vger.kernel.org; 'Erik Faye-Lund'
> >> > Subject: Re: [PATCH v2] Support non-WIN32 system lacking poll() while 
> >> > keeping the WIN32 part intact
> >> >
> >> > "Joachim Schmitz" <j...@schmitz-digital.de> writes:
> >> >
> >> > > Different, but related question: would poll.[ch] be allowed to 
> >> > > #include "git-compat-util.h"?
> >> >
> >> > Seeing other existing generic wrappers directly under compat/,
> >> > e.g. fopen.c, mkdtemp.c, doing so, I would say why not.
> >> >
> >> > Windows folks (I see Erik is already CC'ed, which is good ;-),
> >> > please work with Joachim to make sure such a move won't break your
> >> > builds.  I believe that it should just be the matter of updating a
> >> > couple of paths in the top-level Makefile.
> >>
> >> Haven't heard anything from the Windows folks yet.
> >>
> >> I'd prefer to move compat/win32/poll.[ch] into compat/poll.
> >> Then adjust a few paths in Makefile and that would be the 1st patch
> >>
> >> A 2nd patch would be my already proposed ones that make this usable for 
> >> others (me in this case ;-)), namely wrapping 2 #inludes.
> >>
> >> diff --git a/compat/poll/poll.c b/compat/poll/poll.c
> >> index 403eaa7..49541f1 100644
> >> --- a/compat/poll/poll.c
> >> +++ b/compat/poll/poll.c
> >> @@ -24,7 +24,9 @@
> >>  # pragma GCC diagnostic ignored "-Wtype-limits"
> >>  #endif
> >>
> >> -#include <malloc.h>
> >> +#if defined(WIN32)
> >> +# include <malloc.h>
> >> +#endif
> >>
> >>  #include <sys/types.h>
> >>
> >> @@ -48,7 +50,9 @@
> >>  #else
> >>  # include <sys/time.h>
> >>  # include <sys/socket.h>
> >> -# include <sys/select.h>
> >> +# ifndef NO_SYS_SELECT_H
> >> +#  include <sys/select.h>
> >> +# endif
> >>  # include <unistd.h>
> >>  #endif
> >>
> >> --
> >> 1.7.12
> >
> > However: this poll implementation, while compiling OK, doesn't work 
> > properly.
> > Because it uses recv(...,MSG_PEEK), it works on sockets only (returns 
> > ENOTSOCK on anything else), while the real poll() works on all
> > kind if file descriptors, at least that is my understanding.
> >
> > Here on HP NonStop, when being connected via an non-interactive SSH, we get 
> > a set of pipes (stdin, stdout, stderr) instead of a
> > socket to talk to, so the poll() just hangs/loops.
> >
> > As git's implementation is based on ('stolen' from?) gnulib's and still 
> > pretty similar, CC to the gnulib list and Paolo
> >
> > Any idea how this could get solved? I.e. how to implement a poll() that 
> > works on non-sockets too?
> > There is some code that pertains to a seemingly similar problem in Mac OS 
> > X, but my problem is not identical, as that fix doesn't
> > help.
> 
> Could you give more context ? Are you speaking about win32 or about HP non 
> stop?

HP NonStop

> If so pipe are broken and unfixable under windows see
> http://www.mail-archive.com/bug-gnulib@gnu.org/msg23365.html

Bye, Jojo


Reply via email to