må 2006-06-19 klockan 00:18 +0300 skrev Tor Lillqvist:
I think it is possible to get the same effect as FD_CLOEXEC, though, by
duplicating the socket using DuplicateHandle() to be non-inheritable,
closing the original, and using the duplicated socket instead. Will have
to try.
Indeed, works
On Mon, 2006-06-19 at 00:18 +0300, Tor Lillqvist wrote:
I think I have a good guess now: The problem is that all sockets by
default are inherited by child processes in Windows. (Like file
descriptors in Unix.)
Ah - we had some wonderful b-a-s bugs for the few sockets we didn't
CLOEXEC
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race? Even
if not, tho, I feel it would be cleaner to unregister in a ::destroy()
if that's a
må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race?
Nah... The impl_finalize()
ah, okay.
Jeff
On Mon, 2006-06-19 at 17:03 +0300, Tor Lillqvist wrote:
må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is
Tor,
Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.
lö 2006-06-17 klockan 02:23 +0300 skrev Tor Lillqvist:
I should still of course also investigate why the other (unknown)
mechanism which causes unregistration to happen anyway on Unix doesn't
work on Windows...
I think I have a good guess now: The problem is that all sockets by
default are
