report on obscure issues: running out of file handles with python under wine

[Luke Kenneth Casson Leighton]

hiya folks,
well the saga continues with using python under wine - i thought i'd
let you know the analysis and clues so far, in case it rings any bells
with anyone, now or in the future.  as you're probably aware, there's
a limit in nt of 2048 file descriptors which has caused a large number
of free software projects quite a lot of grief , e.g. this:
http://bugs.mysql.com/bug.php?id=24509.  it turns out that python is
no different, and i'm just in the process of investigating whether
compiling every single c-based module as a builtin saves me enough
file handles to be able to not hit the 2048 handles limit.
it's really quite stunning.  even something as simple as running a
single small test script can result in 1,400 file handles being used
up. by the time you get to things like the popen-replacement (see msdn
KB: Q190351 for a simple code example).
anyway - what prompted me to write was that i ran the python.exe with
msvcr80 on wine, and the popen-like code segfaulted.  under win32
naitive (an actual XP qemu) it failed - gracefully.
but, weirdly, python.exe _without_ msvcr80 did _not_ segfault, but,
again, same code on XP qemu'd failed gracefully.
so, matrix:
          wine      xp-qemu'd
vc80  segfault   error
vc71  ok            error
in other words, i'm beginning to suspect that the reason for that
msvcr80 segfault i was investigating last week is because of running
out of file handles, and wine doesn't _have_ that 2048 file descriptor
limit that msvcr80 is assuming actually exists.  either that, or when
you _do_ reach that limit, it results in corruption that an app
running msvcr71 doesn't notice.  or something.
the reason i haven't raised this as a bugreport is because i really
don't exactly know what's going on - there are just rather a lot of
empirical observations that are ... "out there" :)  so i apologise for
this being a bit long, and not very specific, and if ever i get
anything specific i'll of course raise it as a bugreqeuest, but i
didn't want to leave this undocumented.
l.