waiting for reply; timeout? [was: "i'll think about it"]

[Rob Landley]

On Sunday 24 September 2006 6:25 am, Bernhard Fischer wrote:
> I consider "Thu Sep 21 13:17:44 PDT 2006" as the starting point.
> 
> At the time of this writing, roughly 62 hours have passed since then.

Ok.  I was working on this last night.

> Don't get me wrong, please. I'm just concerned about the rate at which
> we're able to make progress.
> How long are we supposed to wait? Another 3 days? A month?

Single digit number of days at most.

> Remember "df -k /" being broken?

Yes.  Where did I leave off on that...  (Rummage...)

Ok, I was generalizing the code in umount.c that reads and reverses the list 
of mount points into an in-memory linked list.  And I was trying to figure 
out if it should be getmountlist() or xgetmountlist(), because it's a funky 
corner case that "umount -a" wants to abort but "umount /something/specific" 
does _not_ want to abort, and the note says "setjmp?" which reminds me:

We could have a global jmp_buf pointer, something like:

  jmp_buf graveyard;
  jmp_buf *to_graveyard = graveyard;

And then main() or run_applet_by_name() or some such could do a 
setjmp(graveyard) and exit from there, and then the xfuncs that currently 
call exit(blah) could instead longjmp(to_graveyard, blah);

The advantage of this is anybody who wants to intercept exit from an 
xfunction() could do so by temporarily repointing to_graveyard.  It also 
makes the nofork() guys happy, and bbsh could theoretically take advantage of 
some of this nofork stuff.  The downside is: it's almost certainly bigger, 
although a bb_exit() wrapper might be able to blunt some of that.

Oh, and this is another case where llist_t wants to be an arbitrary struct 
with "next" as its first member but the rest of the data in the struct 
itself, rather than a two member struct with a next * and a void pointer to a 
separately allocated chunk of data.

I have the todo list of doom.

> http://busybox.net/lists/busybox/2004-May/011643.html
> Entered 03-12-05 20:11 as http://bugs.busybox.net/view.php?id=145
> landley> 2006-Jul-11 "I'll fix it."
> http://www.busybox.net/lists/busybox/2006-July/023142.html
> 
> 
> 
> There are several things that are "waiting". Let's continue with df,
> since we're already there:

Yeah, I need to work on that.  Ok, I can do that now.  Just abuse my way past 
those two issues and clean up the generic infrastructure to make this stick 
out less later...

Darn it, coffee shop's closing.  Back in 20 minutes...

Rob
-- 
Never bet against the cheap plastic solution.