BuffaloFeeds » Comments for Josh the Outspoken » April 2011

Feeds

105363 items (97572 unread) in 19 feeds

• 2 Star (84 unread)
• John Carrino (12 unread)
• Comments for Josh the Outspoken (296 unread)
• Josh (34 unread)
• Planet Matt (595 unread)

• MAKE Magazine (20292 unread)
• Instructables.com (35006 unread)
• Hack A Day (5017 unread)
• Toolmonger (7776 unread)

• Exploration Through Example
• Paul Graham: Unofficial RSS Feed (113 unread)
• Stevey's Blog Rants (34 unread)
• Joel on Software (207 unread)
• Gibson Blog (239 unread)
• Adventures in Bloggery (123 unread)

• Slashdot (25203 unread)
• Economist.com Global Agenda (1412 unread)
• Ruby Inside (922 unread)

• Templar, Arizona (207 unread)

Comments for Josh the Outspoken (8 unread)

• 

  Comment on EINTR and PC loser-ing (The “Worse Is Better” case study) by Brian Maher

  Posted: April 30th, 2011, 8:12am MDT by Brian Maher

  Hi Josh,

  I found this blog entry really interesting… I hadn’t thought about the fact that the PC losering problem is really about signals.

  One example of where EINTR is important to me is when doing graceful server shutdowns. In particular, if I have a SIGTERM handler that sets a global “shutdown” variable, then I need to check if accept() returned EINTR and if so, did the “shutdown” global variable get set.

  I like your idea of having separate system calls that retry if EINTR is returned, but it is simple enough to write those functions in a user program. In fact, it is probably a good practice to wrap most system calls to deal with other notoriously difficult to deal with errors such as ENOMEM.

• 

  Comment on upb status and preliminary performance numbers by Josh

  Posted: April 29th, 2011, 4:25pm MDT by Josh

  Thanks for the correction Russ. I was misled by the Wikipedia page about JSON.

  I think it is safe to say, though, that interpreting all JSON numbers as double-precision is sufficient to be a usable JSON parser, since that what common implementations do.

• 

  Comment on upb status and preliminary performance numbers by Russ Cox

  Posted: April 27th, 2011, 10:38pm MDT by Russ Cox

  You say that JSON only supports double-precision numbers but that’s not true. JSON only defines the syntax of its numbers, not the semantics. There is no limit to the size or precision of numbers formatted as JSON.

• 

  Comment on upb status and preliminary performance numbers by Buffalo

  Posted: April 26th, 2011, 1:25pm MDT by Buffalo

  Congrats Josh!

• 

  Comment on upb status and preliminary performance numbers by Phil

  Posted: April 26th, 2011, 1:02pm MDT by Phil

  That must be a pretty awesome feeling.

• 

  Comment on Gazelle/upb status by Ricky

  Posted: April 25th, 2011, 3:17pm MDT by Ricky

  Is there a reasonably stable version of upb that can be used in production? If it works well enough, I guess I could fix small issues myself if it comes to that… but how “done” is your implementation really? It sounds brilliant by the way.

• 

  Comment on EINTR and PC loser-ing (The “Worse Is Better” case study) by John "Z-Bo" Zabroski

  Posted: April 25th, 2011, 11:14am MDT by John "Z-Bo" Zabroski

  “Worse is better” systems incrementally improve by responding to user needs.

  Are your conclusions meant to be generalized, and, if so, in what way?

  For example, web browsers adopted the Robustness Principle and now we have the messy result of software that has to know how to interpret its formats, rather than distributing the format with the interpreter (Joel Spolsky’s rant titled “Martian Headsets” gives a good summary of why this is such a bad approach, and what we are stuck with). The web browser example is actually not mine; it is Alan Kay’s classic example of Doghouse and Pyramid architecture from his classic OOPSLA talk, “The Computer Revolution Hasn’t Happened Yet” (google it). He essentially argues, implicitly, the Smalltalk way is better — and before Tim Berners-Lee invented the Web Browser, Xerox PARC had an Object Browser built into the operating system via the Smalltalk system.

• 

  Comment on EINTR and PC loser-ing (The “Worse Is Better” case study) by Josh

  Posted: April 24th, 2011, 12:37am MDT by Josh

  Thanks for the comment! I agree that providing EINTR for applications that want it can possibly be useful. But I think the way it’s exposed in the API breaks the rule of “make simple things easy and hard things possible.” Since it’s very uncommon that a program wants to handle EINTR, I think it would be better to have separate versions of the functions (or a boolean parameter to these functions) that lets you enable EINTR only for calls where you want to handle it.

  // Standard write() call.  Will never return EINTR.
  ssize_t write(int fildes, const void *buf, size_t nbyte);
   
  // Interruptible write() call, may return EINTR.
  ssize_t interruptible_write(int filedes, const void *buf,
                              size_t nbyte);

  As it’s written, since SA_RESTART is a property of the signal handler and not of the interruptible system call itself, all such system calls are potentially interruptible, so they all have to handle EINTR.

TOP Gregarius 0.5.4 Tentatively valid XHTML1.0, CSS2.0 Last update: Sun Apr 15 21:49:26 2012