[Mingw-users] sys/poll.h

[Jeffrey Stephen]

Hi,

Does anyone know if the "poll" function has been ported to MinGW?

I am trying to install mpich (Message Passing Interface) and the
configure script fails because MinGW doesn't have sys/poll.h

cheers
steve

************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.
************************************************************************

[Daniel K. O.]

Post by Jeffrey Stephen
I am trying to install mpich (Message Passing Interface) and the
configure script fails because MinGW doesn't have sys/poll.h

They seem to distribute Windows binaries. Maybe they use a different
build procedure for Windows, or their configure script is broken. Either
way, this is not related to MinGW. If you need *nix emulation (which
mpich2 apparently doesn't), use Cygwin.



---
Daniel K. O.

[Tor Lillqvist]

Post by Jeffrey Stephen
Does anyone know if the "poll" function has been ported to MinGW?

That is not what MinGW is, something which would offer "ported" system
calls from POSIX.

That said, it is trivial to write a replacement poll() that has the
same API as the real poll() but uses select() internally instead. Of
course, it won't have any of the fundamental extra functionality that
poll() offsers over select(). (I don't remember what that extra
functionality is right now.) When used on top of Winsock, it will
still have the same restriction that Winsock's select() has: work only
on sockets.

In fact, there is such a function in GLib, 45 lines... Note that GLib
is LGPL, so don't just copy it unless your software is licensed
compatibly. Not that it could be written much differently. Look for
the *second* g_poll() in glib/gmain.c. (The first one is for Windows
HANDLEs, and completely different.)

--tml

[Keith MARSHALL]

Post by Jeffrey Stephen
Does anyone know if the "poll" function has been ported to
MinGW?

Short answer: `no'.

The issue isn't whether, or not, that poll has been ported to
MinGW, (or rather, as a native Win32 function), but that the
client application must be adapted to use the native winsock
API, which does not support poll.

This very topic was discussed earlier this week; please check
the list archives, before posting.

Post by Jeffrey Stephen
I am trying to install mpich (Message Passing Interface) and
the configure script fails because MinGW doesn't have
sys/poll.h

So, the mpich application itself needs to be ported, to use
winsock. It seems like someone may have already done that;
see Daniel K. O.'s reply.

Regards,
Keith.

[Keith MARSHALL]

Post by Jeffrey Stephen
I am trying to install mpich (Message Passing Interface)
and the configure script fails because MinGW doesn't have
sys/poll.h

They seem to distribute Windows binaries. Maybe they use a
different build procedure for Windows, or their configure script
is broken.

The former seems more probable; a number of projects provide a
completely separate build infrastructure, to support native builds
using MSVC.

Either way, this is not related to MinGW.

Actually, it is! In the paragraph you snipped, the OP asked if it
was possible to use the poll function in MinGW. That the answer is
`no', or even that the question had already been asked, by another
user, and answered as recently as the beginning of this week, does
not make it any less relevant.

If you need *nix emulation (which mpich2 apparently doesn't),
use Cygwin.

Daniel, please do not dismiss questions like this, on this list!
It may be appropriate to suggest that a user may wish to consider
using Cygwin, as an alternative to MinGW, if the porting effort to
use MinGW seems too onerous, but that is *his* choice to make, not
ours. It may be that the user has some reason for not wishing to
use Cygwin, and is prepared to put in the effort to create a native
port. `Go away, and just use Cygwin' is *not* the attitude we want
to convey. On the contrary, we should encourage such discussion of
MinGW's capabilities, and techniques for working around limitations
of the underlying Win32 API; therein lies the means to a broader
knowledge base for all.

Regards,
Keith.

[Daniel K. O.]

Post by Keith MARSHALL

Either way, this is not related to MinGW.

Actually, it is! In the paragraph you snipped, the OP asked if it
was possible to use the poll function in MinGW. That the answer is
`no', or even that the question had already been asked, by another
user, and answered as recently as the beginning of this week, does
not make it any less relevant.

I think you are focusing in answering what he asked (poll), instead of
what he needs to know (mpich).
Maybe I wasn't clear in what was my goal in the original message, and
left it open to be misinterpreted.

Post by Keith MARSHALL
Daniel, please do not dismiss questions like this, on this list!

I was trying to address his need to compile mpich(2), so I pointed that he:
1) probably doesn't need to because of the availability of win32 binaries
2) doesn't need sys/poll.h, because mpich2 also works on Windows
3) Cygwin provides the emulation you may need for unix; (the possibility
that the win32 binary actually uses Cygwin)

So if for some reason he can't / don't want use the win32 binary, he
just needs to find out how to compile it; that directly depends on the
mpich2 developers (and maybe Cygwin, or the "other supposed build
process" developers). So he either doesn't need poll (and thus don't
need MinGW's list help providing one), or he needs poll from the same
place the win32 mpich2 binary is already getting it.

Yes, the discussion IS related to MinGW, but the solution isn't. I'm
sorry for causing confusion. I wasn't trying to "just send the newbie
away", if that was the impression; I think I chose the wrong words. I'll
be more careful in the future.


---
Daniel K. O.

[James Steward]

Post by Daniel K. O.

Post by Keith MARSHALL

Either way, this is not related to MinGW.

Actually, it is! In the paragraph you snipped, the OP asked if it
was possible to use the poll function in MinGW. That the answer is
`no', or even that the question had already been asked, by another
user, and answered as recently as the beginning of this week, does
not make it any less relevant.

I think you are focusing in answering what he asked (poll), instead of
what he needs to know (mpich).
Maybe I wasn't clear in what was my goal in the original message, and
left it open to be misinterpreted.

Post by Keith MARSHALL
Daniel, please do not dismiss questions like this, on this list!

1) probably doesn't need to because of the availability of win32 binaries
2) doesn't need sys/poll.h, because mpich2 also works on Windows
3) Cygwin provides the emulation you may need for unix; (the possibility
that the win32 binary actually uses Cygwin)
So if for some reason he can't / don't want use the win32 binary, he
just needs to find out how to compile it; that directly depends on the
mpich2 developers (and maybe Cygwin, or the "other supposed build
process" developers). So he either doesn't need poll (and thus don't
need MinGW's list help providing one), or he needs poll from the same
place the win32 mpich2 binary is already getting it.
Yes, the discussion IS related to MinGW, but the solution isn't.

Unless, as it was pointed out, that a replacement for poll was written
for MinGW. Possibly using select, which of course would only work on
sockets in Windows, but may be all that's needed to compile mpich under
MinGW.

So could it be worth writing a functionally limited poll for MinGW?

Regards,
James.

[Brian Dessent]

Post by James Steward
Unless, as it was pointed out, that a replacement for poll was written
for MinGW. Possibly using select, which of course would only work on
sockets in Windows, but may be all that's needed to compile mpich under
MinGW.
So could it be worth writing a functionally limited poll for MinGW?

That's kind of a slippery slope though, as I see it. It is definitely
possible to implement a certain number of functions that MSVCRT lacks in
terms of existing MSVCRT or Win32 functions. And I'm sure that
libraries that do this are very useful (see for example, gnulib.) But
as a project, how far does MinGW itself really want to go down this
road? If you write a replacement poll(), then do you also write a
(random example) replacement getpwent()? Where do you draw the line?
And since users of MinGW expect as few dependencies as possible, it
means any of this that you do implement must be in terms of static
libraries or copy-and-paste drop-in functions, both of which seem to
defy the notions of efficiency and code hygiene that shared libraries
bring to the table. And at the risk of sounding like a broken record,
the title of this project does begin with the word "Minimalist".

Brian

[James Steward]

Post by Brian Dessent

Post by James Steward
Unless, as it was pointed out, that a replacement for poll was written
for MinGW. Possibly using select, which of course would only work on
sockets in Windows, but may be all that's needed to compile mpich under
MinGW.
So could it be worth writing a functionally limited poll for MinGW?

That's kind of a slippery slope though, as I see it. It is definitely
possible to implement a certain number of functions that MSVCRT lacks in
terms of existing MSVCRT or Win32 functions. And I'm sure that
libraries that do this are very useful (see for example, gnulib.) But
as a project, how far does MinGW itself really want to go down this
road? If you write a replacement poll(), then do you also write a
(random example) replacement getpwent()? Where do you draw the line?
And since users of MinGW expect as few dependencies as possible, it
means any of this that you do implement must be in terms of static
libraries or copy-and-paste drop-in functions, both of which seem to
defy the notions of efficiency and code hygiene that shared libraries
bring to the table. And at the risk of sounding like a broken record,
the title of this project does begin with the word "Minimalist".

Lol. Yes Brian. Quite correct. I'll rephrase. Maybe the OP could
write his own poll replacement for the purposes of building mpich - if
that were the only stumbling block. Or possibly rewrite chunks of
mpich. I know what I'd rather try to begin with.

Regards,
James.

[Keith MARSHALL]

Post by Tor Lillqvist

Post by Jeffrey Stephen
Does anyone know if the "poll" function has been ported to
MinGW?

That is not what MinGW is, something which would offer "ported"
system calls from POSIX.

This isn't strictly true.

As a general principle, yes, it is not MinGW's goal to provide a
fully featured POSIX porting library; if that is your requirement,
then you will probably find that Cygwin is a better fit for your
needs. However, MinGW does provide a small selection of functions,
which add some POSIX like capabilities to the standard Win32 APIs.

I'm always willing to consider further extending that set of extra
functions, on condition that I am offered public domain code to
implement the added functionality, and that the added code doesn't
grossly inflate the size of the mingw-runtime package.

I will also consider distributing additional add-on libraries, such
as those offered in our mingwPORTS or `Contributed' distributions;
such additional libraries must be distributable either in the public
domain, or under a free, and open source, licence, and I will expect
the contributor to commit to providing free ongoing support, via
this list.

Regards,
Keith.