edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev]  Error Legs
Date: Fri, 07 Feb 2014 12:57:53 -0500	[thread overview]
Message-ID: <20140107125753.eklhad@comcast.net> (raw)

> exit on out-of-memory inside my_ErrorReporter.

Very good.
I pushed a small change to use the symbol and message we already had for this
condition, rather than making a new one.
I try to avoid extra messages, as they have to be translated.
When you do add a message though, append zeros for the other languages,
just so I can keep track of outstanding messages that haven't yet been
translated into this or that.

Yes, as you point out we could exit on

if(stringEqual(message, "out of memory")

I'm thinking maybe not though.
Marching on won't lead to a segfault,
and as Adam notes, another buffer may have a lot of work in it,
so why exit.
It's not worse or better than the other js errors,
like undefined variable.
Of course, if truly out of memory,
the next js get object call will probably fail,
and that one will probably exit.
So maybe

if(stringEqual(message, "out of memory")) {
print some helpful warning about memory and risk of exit
and saving your buffers.
}

Your demo program is simple,
but I would point out that it doesn't fail if you replace {} with 37.
An array with a million elements still fits,
but an array of a million arrays, with all the associated overhead
of all those objects, that doesn't fit.
Hard to imagine a web page making a million arrays.
So it makes me wonder if we ever bump up against this limit
on a real website.
Are we jumping at shadows, or is this really an issue?
If 4 meg isn't enough, 16y probably is.
My gut tells me the segfaults might come from somewhere else.
Then again, you could have many web pages, with many
contexts and pages, in one edbrowse session.
IDK


Karl Dahlke

             reply	other threads:[~2014-02-07 17:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 17:57 Karl Dahlke [this message]
2014-02-07 18:23 ` Chris Brannon
2014-02-09 10:45   ` Adam Thompson
2014-02-09 11:10     ` Adam Thompson
  -- strict thread matches above, loose matches on Subject: below --
2014-02-09 14:48 Karl Dahlke
2014-02-09 15:21 ` Adam Thompson
2014-02-09 14:18 Karl Dahlke
2014-02-09 15:13 ` Adam Thompson
2014-02-07 20:06 Karl Dahlke
2014-02-07 19:37 Karl Dahlke
2014-02-07 19:55 ` Chris Brannon
2014-02-07 14:01 Karl Dahlke
2014-02-07 15:05 ` Chris Brannon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140107125753.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).