On Mon, Nov 05, 2007 at 02:13:20PM -0800, Scott Lamb <[EMAIL PROTECTED]> wrote:
> >Its higher than necessary, and more complex than neccessary.
>
> Higher than necessary? I don't care; it's worth it.
>
> More complex than necessary? Not really.
Well, I gave an example that is less complex and more efficient, the best of
all worlds. And fully binary-compatible.
> >responsible.
>
> Erm, no. In the ENOMEM case, I know which fd you decided to kill, though
> not actually that you've killed it. ENOMEM is not a per-file descriptor
> problem.
The word "kill" is misleading, the fd is still there, alive and
kicking. But the event handler has been stopped.
> I'm looking at the Linux kernel source code now (core_sys_select), and
> you are wrong on Linux as well:
Maybe differeing linux versions? I definitely get ENOMEM with gigabytes of
free memory whne exceeding the configured limit.
Of course, linux might *also* return ENOMEM for transient conditions.
> might be useful, but it's nothing the caller can't do on its own by
> retrying the failed function.
The problem is that *all* callers will need to do this, and this is not
something I will ever require of all callers.
As a callback will solve your problem (the special case) and will make it
much easier for the general case, it definitely seems the better solution,
leading to better programs in general.
> which allowed attributes specified at eventloop creation time
> (extensible without further API changes). One of them might have been
>
> libname_eventloop_attr_setenomem(libname_eventloop_attr_t *, void
> (*enomem_callback)(/*undecided*/), void *enomem_callback_arg);
Thats interesting, but I guess i will go for a simpler set-callback
function.
The question still remains under what conditions exactly to call it - *alloc
is obvious, but should there be a separate handler
> >>* any X11 application is screwed if you close its connection to the server
> >
> >Uhm, no? :)
>
> Uhm, yes.
Repeating untruths doesn't make them any truer. You confuse the default
action of terminating your program with "being screwed", but that is
simply not true (even if libX11 makes this hard, other X libs such as the
more modern XCB don't).
Most X11 apps just exit, but thats not a law.
> Not necessarily. Servers do occasionally reload their listen sockets
> (SIGHUP handlers); they just don't have logic to do so on demand from a
> crazy library.
They still have to handle accept errors, though.
> >(There are userspace nfs daemons, but even if they use libevent, they are
> >far more broken and fragile than the standard nfs daemons in linux).
>
> Please don't assume I'm a moron.
I don't, but you keep making untrue statements that I correct. If you think I
assume you are a moron by correcting you, you could just stop making false
generic statements such as above and we will not run into any problems :)
However, let me repeat that I do not assume you are a moron, and it probably
isn't too nice to assime I did. Its certainly not healthy for our otherwise
very productive discussion that I would hate to lose :(
> would not have said this if I hadn't actually seen libevent-based NFS
> code that ships on real systems.
> Specifically, I'm talking about the version of rpc.idmapd running by
> default on RHEL 5.0.
which actually is not a nfs daemon (just like portmap is not an nfs
daemon, its a specific service that cna optionally be used by the nfs
daemons),.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
