Neal Norwitz wrote:
> On 2/11/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
>>>[Tim telling how I broke pyuthon]
>>
>>[Martin fixing it]
>
>
> Sorry for the breakage (I didn't know about the Windows issues).
> Thank you Martin for fixing it. I agree with the solution.
>
> I was away from mail,
On 2/11/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>> [Tim telling how I broke pyuthon]
> [Martin fixing it]
Sorry for the breakage (I didn't know about the Windows issues).
Thank you Martin for fixing it. I agree with the solution.
I was away from mail, ahem, "working".
n
_
[Tim]
>> The code in selectmodule when _MSC_VER is _not_ defined complains if a
>> socket fd is >= FD_SETSIZE _or_ is < 0. But the new code in
>> socketmodule on non-Windows boxes is happy with negative fds, saying
>> "fine" whenever fd < FD_SETSIZE. Is that right or wrong?
[Martin]
> I think it
Tim Peters wrote:
> The code in selectmodule when _MSC_VER is _not_ defined complains if a
> socket fd is >= FD_SETSIZE _or_ is < 0. But the new code in
> socketmodule on non-Windows boxes is happy with negative fds, saying
> "fine" whenever fd < FD_SETSIZE. Is that right or wrong?
I think it is
[Martin v. Löwis]
> For the moment, I have committed Tim's original proposal.
Thank you! I checked, and that fixed all the test failures I was
seeing on Windows.
> Moving the macro into pyport.h could be done in addition. That
> should be done only if selectmodule is also adjusted; this currentl
Ronald Oussoren wrote:
> If I understand this discussion correctly that code that would be
> conditionalized using this define is the IS_SELECTABLE macro in
> selectmodule.c and very simular code in other modules. I'd say that
> calling the test _Py_IS_SELECTABLE and putting it into pyport.h
> as T
On 10-feb-2006, at 23:49, Martin v. Löwis wrote:
Tim Peters wrote:
I don't know. Of course it misses similar new tests added to _ssl.c
(see the msg that started this thread), so it spreads beyond just
this. Does it do the right thing for Windows variants like Cygwin,
and OS/2? Don't know.
Tim Peters wrote:
> Does it do the right thing for Windows variants like Cygwin, and OS/2?
I can at least say that the Cygwin implements a full POSIX facade in
front of Windows sockets, so it would be important that the code in
question is used to protect it as well. Also, MS_WINDOWS is not def
Tim Peters wrote:
> ? Sorrry, don't know what you're talking about here. Python's
> selectmodule.c #defines FD_SETSIZE before it includes winsock.h on
> Windows, so Microsoft's default is irrelevant to Python. The reason
> selectmodule.c uses "!defined(FD_SETSIZE)" in its
Not that this is reall
[Martin v. Löwis]
> I see. How does Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE help here?
By naming a logical condition as opposed to a list of
platform-specific symbols that aren't documented anywhere. For
example, I have no idea exactly which compiler+OS combinations define
MS_WINDOWS, so "#ifdef MS_WIN
Tim Peters wrote:
> [Martin v. Löwis]
> > In any case, POSIX makes it undefined what FD_SET does when the
> > socket is larger than FD_SETSIZE, and apparently clearly expects
> > an fd_set to be a bit mask.
>
> Yup -- although the people who designed the fdset macros to begin with
> didn't appear
Tim Peters wrote:
> I don't know. Of course it misses similar new tests added to _ssl.c
> (see the msg that started this thread), so it spreads beyond just
> this. Does it do the right thing for Windows variants like Cygwin,
> and OS/2? Don't know.
I see. How does Py_SOCKET_FD_CAN_BE_GE_FD_SETS
[Martin v. Löwis]
>>> So FD_SETSIZE is 64 on Windows,
[Tim Peters]
>> In Python FD_SETSIZE is 512 on Windows (see the top of selectmodule.c).
[Scott Dial]
> Although I agree, in terms of the socketmodule, there was no such define
> overriding the default FD_SETSIZE, so you are both right.
? Sor
[Tim]
>> I suggest skipping the new crud conditionalized on a symbol like
>>
>> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
[Martin]
> Hmm... How about this patch:
I don't know. Of course it misses similar new tests added to _ssl.c
(see the msg that started this thread), so it spreads beyond just
this
Tim Peters wrote:
> [Martin v. Löwis]
>> So FD_SETSIZE is 64 on Windows,
>
> In Python FD_SETSIZE is 512 on Windows (see the top of selectmodule.c).
>
Although I agree, in terms of the socketmodule, there was no such define
overriding the default FD_SETSIZE, so you are both right.
--
Scott Di
Martin v. Löwis wrote:
> Tim Peters wrote:
>> I suggest skipping the new crud conditionalized on a symbol like
>>
>> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
>>
>
> Hmm... How about this patch:
>
> Index: Modules/socketmodule.c
> ===
>
[Martin v. Löwis]
> I think the Windows interpretation is actually well-designed: FD_SETSIZE
> shouldn't be the number of the largest descriptor, but instead be the
> maximum size of the set.
It's more that the fdset macros were well designed: correct code
using FD_SET() etc is portable across Wi
Tim Peters wrote:
> I suggest skipping the new crud conditionalized on a symbol like
>
> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
>
Hmm... How about this patch:
Index: Modules/socketmodule.c
===
--- Modules/socketmodule.c (Revisi
[Scott Dial]
> This begs the question then whether the check that is implemented has
> any relevance to any platform other than Linux. I am no portability
> guru, but I have to think there are other platforms where this patch
> will cause problems. For now at least, can we at least do some
> prepro
Thomas Wouters wrote:
> I doubt it will have problems on other platforms. As Tim said, FD_SETSIZE is
> mandated by POSIX. Perhaps some platforms do allow larger sizes, by
> replacing the FD_* macros with functions that dynamically grow whatever
> magic is the 'fdset' datatype. I sincerely doubt it'
Scott Dial wrote:
> This begs the question then whether the check that is implemented has
> any relevance to any platform other than Linux. I am no portability
> guru, but I have to think there are other platforms where this patch
> will cause problems.
The patch is right on all platforms confo
On Fri, Feb 10, 2006 at 03:24:28PM -0500, Scott Dial wrote:
> Tim Peters wrote:
> >No more than it had been jarred ;-) Well, a bit more: it was
> >possible to pass a first argument to select() that was larger than
> >FD_SETSIZE. In effect, FD_SETSIZE had no meaning.
>
> any relevance to any pl
Tim Peters wrote:
> No more than it had been jarred ;-) Well, a bit more: it was
> possible to pass a first argument to select() that was larger than
> FD_SETSIZE. In effect, FD_SETSIZE had no meaning.
This begs the question then whether the check that is implemented has
any relevance to any p
[Thomas Wouters]
> Perhaps the memory you have is of select-lookalikes, like poll(),
No, it was definitely select(), and on a 64-bit Unix (probably _not_
Linux) that allowed for an enormous number of sockets.
> or maybe of vendor-specific (and POSIX-breaking) extensions to select().
Yes, it must
On Fri, Feb 10, 2006 at 12:36:09AM -0500, Tim Peters wrote:
> [Tim]
> > ... FD_SETSIZE is the maximum number of distinct fd's an fdset can
> > hold, and the numerical magnitude of any specific fd has nothing to do
> > with that in general (they may be related in fact on Unix systems that
> > imple
[Tim]
> ... FD_SETSIZE is the maximum number of distinct fd's an fdset can
> hold, and the numerical magnitude of any specific fd has nothing to do
> with that in general (they may be related in fact on Unix systems that
> implement an fdset as "a big bit vector" -- but Windows doesn't work
> that
Tim Peters wrote:
> I _suspect_ that rev 42253 introduced these problems. For example, that
> added:
>
> + /* Guard against socket too large for select*/
> + if (s->sock_fd >= FD_SETSIZE)
> + return SOCKET_INVALID;
>
> to _ssl.c, and added
>
> +/* Can we call select()
27 matches
Mail list logo
