On Thu, Feb 25, 2016 at 06:44:19PM +0300, Nick Zavaritsky <[email protected]>
wrote:
> >> 1) UB from the libev point of view, or
> >> 2) works with certain versions of libev on certain OSes, but may break
> >> without warning, or
> >> 3) is fully supported and is a part of the public API contract.
> >
> > It's certainly 1 or 2.
>
> I am glad it was stated in clear now.
After reading the rest of your mail, I frankly am not sure I appreciate
your tone.
> Remember a discussion a while ago when a patch was submitted to work around a
> situation when libev runs out of file descriptors?
Yup.
>
> Back then you suggested long jump, but today you admit it is unreliable.
Not then and not now do I "admit" it is unreliable. Why do make this up?
Please don't put words in my mouth that I never said, I don't appreciate
that. At all.
> This is a reasonable programming model though not universal. You surely won’t
> assume that an embedded system has plenty of RAM. It is also possible to turn
> overcommit off.
It's clearly not libev's programming model, so I don't quite see why you
bring it up.
> The case with the descriptors running out falls somewhere in-between.
Yes. To quote yourself, with careful programming it is possible to avoid
this kind of errors.
However, while it might be possible, it's certainly very hard, and IMnsHO
(as backed up by ample real world evidence), relying on this is doomed.
> If I was to consider adding resiliency to fd shortage in a library like libev
> I would have asked the following questions:
libev is already resilient to fd shortage - you probably work on very
specific definitions of resilient.
> B) Not quite. Controlling fd usage manually is hard due to many existing
> libraries consuming descriptors internally. Besides, it is complex and feels
> awkward.
As is controlling memory and stack usage. I'm not seeing what your pointis?
> C) It depends. But generally, yes. Especially, in a network server, that is
> already prepared to handle connection errors.
Sure, that's why libev allows applications to deal with this.
> > Just saying... all this sounds like some inane customer feature request
> > form a customer who doesn't know what he is doing and wants to go headlong
> > through the nearest wall.
>
> May be I am missing something and a peace of advice will be greatly
> appreciated.
Well, the above is just my feeling of how this sounds like - it appears
you want to go through a wall by forcing a solution that really isn't
easier than much better solutions that are already available.
Adding some kind of error returns to basically every function in libev, and
wrapping every call done at any time does not sound like a reasonable plan
for libev users,a nd doesn't seem like a reasonable plan to improve anything.
It very much sounds like "we decided to do it this way, no matter what,
the wall in front of me be damned".
Wrapping ev_async isn't enough - libev can run out of fd's or memory and
potentially other rersources at basically any time.
If you want a good plan to deal with these issues, then dealing with these
issues by e.g. avoiding the condition (by not using too many fds) or
reporting the misconfiguration and relying on a service manager sounds a lot
more reasonable.
Even if libev had some interface thast would suit you, you have the same
issues with a host of kernel interfaces, such as memory allocation or
linux's non-posix accept behaviour, that you have to deal with and that
are similar.
I am doubtful that this would be a real-world requirement, or a real-world
improvement to libev or its users.
> We are spawning a new thread with a dedicated event loop. Sometimes it
> fails due to fd shortage when we setup ev_async used for communication
> with the thread. We would like to shutdown the thread in a clean way
> and to deliver an error into the procedure waiting for the thread’s
> completion. The procedure is fully prepared to handle the error (maybe
> it attempts to restart processing sans the dedicated thread, or it just
> throws the hands into the air.)
If it is fully prepared to handle the error, then why not rely on that?
I am also not sure how "throwing hand sin the air" is considered "fully
prepared to handle the error"?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/libev
