On Wed, Mar 21, 2018 at 5:29 AM, Ben Noordhuis <[email protected]> wrote:
> On Wed, Mar 21, 2018 at 1:10 AM, CM <[email protected]> wrote: > > On Tuesday, March 20, 2018 at 4:26:38 AM UTC-5, Ben Noordhuis wrote: > >> > >> On Tue, Mar 20, 2018 at 9:37 AM, CM <[email protected]> wrote: > >> > What is the reason behind existence of uv_fatal_error()? Asking from a > >> > position of someone who doesn't want 3rd party library/component to > kill > >> > my > >> > process because CreateEvent() has failed. > >> > >> It's for unexpected errors that aren't recoverable and make it > >> impossible for libuv to function. > > > > Why these situations are considered unrecoverable? I.e. what prevents > > related function to return some error code if GetProcAddress or > CreateEvent > > failed? I noticed that unix-related code doesn't seem to call abort(). > Is it > > some windows-specific situation that breaks libuv model and (instead of > > changing the model) authors decided to abort instead? > > The UNIX code calls abort() in plenty of places. Huh... I need to look more closely at these spots. > Generally speaking, > when an error occurs that cannot logically happen, libuv aborts rather > than truck on in some poorly defined state. > Failing to create an event object is not something that "cannot logically happen" -- it can happen quite logically. Running out of resources is somewhat common situation -- granted 99% of software out there isn't written to handle this, but some is. Ideally, libuv docs should mention situations in which it aborts the process to avoid surprises for end user. > Out-of-memory errors are a special case. Because for all practical > purposes they never happen* and because no one ever tests their OOM > error handling, libuv aborts. > > * To wit, at least on Linux a process is more likely to get killed by > the operating system than it is to see a ENOMEM error. > I write my code to always handle lack of resources gracefully. I understand sometimes it may not be possible due to limitations of design -- in which case this will be mentioned in documentation. Under Linux you can observe ENOMEM if you switch overcommit off or limit your process memory (via ulimit) or have custom memory allocation mechanisms or you run 32 bit binary on 64-bit hardware with more than 4Gb of memory or trigger allocation of "too large" memory chunk. > > Are those surprises mentioned in documentation or reading code is the > only > > way to discover them? > > The latter. But, barring bugs in libuv or your application, you > should never run into them. If you do and you feel there is a > legitimate way for libuv to handle the failure, open an issue for > discussion. > Will do. -- Sincerely yours, Michael. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
