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
Hi,
[EMAIL PROTECTED] wrote:
H... I am not really convinced yet; I mean even when I have
100 mails with the same email address in my Inbox (which seems
a lot from one person!). The email-address would be 20 chars; now having
'm all in one string saves me, even in this extreme case, only
On Mon, 2006-06-19 at 11:56 +0200, Florian Boor wrote:
as long as we talk about individual senders this is true, but if you think
about
mailinglists and all this automated server notifications this could save
quite
some memory. As long as it is possible to implement this without a too big
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.
