[00:19:09] --- Russ has left: Disconnected [00:43:36] --- Simon Wilkinson has become available [02:44:39] --- geekosaur has left [02:53:42] --- Simon Wilkinson has left [04:04:52] --- Simon Wilkinson has become available [04:11:12] --- Simon Wilkinson has left [05:12:32] --- pod has left [05:12:54] --- pod has become available [07:28:40] --- deason has become available [08:17:43] --- Simon Wilkinson has become available [08:33:14] --- geekosaur has become available [09:05:35] --- Simon Wilkinson has left [09:09:50] --- andersk has left [09:10:42] --- jaltman has left: Replaced by new connection [09:10:42] --- jaltman has become available [09:17:22] --- ezyang@mit.edu/barnowl has left [09:31:03] --- jaltman has left: Disconnected [09:31:12] --- jaltman has become available [09:47:59] --- Russ has become available [09:53:45] --- andersk has become available [10:19:43] > Hmmm. I wonder if I've broken gerrit emails. did we lose some? I've gotten some since then, but I feel like I missed some others around this time [10:20:07] (as in, I added myself as a reviewer to something around when you said that, but I don't think I ever got the email for it) [10:20:28] unless it doesn't email you when you add yourself anymore [10:22:40] --- Russ has left: Disconnected [13:10:44] could anyone tell me the reasoning for the client (sometimes) using background daemons (BOP_STORE) for storing data on a close? [13:11:21] that is, the logic where it uses a daemon if one is idle (and waits for the req to finish), and otherwise it does the store itself [13:11:26] tht's how storebehind works [13:12:00] but it waits for the brequest to finish [13:12:54] i thought it only waited if you were not in storebehind mode. but right now i'm using ssh from ipad on a bus, so can't easily look [13:13:34] after the BQueue it while ((tb->flags & BUVALID) == 0) { tb->flags |= BUWAIT; afs_osi_Sleep(tb); } [13:14:07] and BUVALID isn't set until afs_StoreOnLastReference returns [13:14:26] that does lok familiar ... i wonder if it did work as i describe and we lost it. or ibm did. [13:20:32] worked this way in 3.6 from ibm. so no [13:32:51] does storebehind work in modern code? I'm not seeing a lot of asynchrony trying it right now, but of course many things could be causing that... [13:46:05] oh, wait, I see it [13:46:19] (or at least how it's supposed to work, whether or not it actually does) [13:47:03] BUVALID is also set by afs_wakeup, which is conditionally called by the storing codepath depending on the async settings, duh [14:39:12] --- jaltman has left: Replaced by new connection [14:39:13] --- jaltman has become available [15:05:23] --- jaltman has left: Disconnected [15:05:31] --- jaltman has become available [15:47:37] --- deason has left [16:04:33] --- jaltman has left: Disconnected [17:34:54] --- geekosaur has left [17:36:20] --- Brandon_CMU has become available [18:11:14] --- Russ has become available [18:55:08] --- jaltman has become available [20:33:35] * Russ sits on his hands to keep from saying rude things about cmake. [20:33:45] At least on the list. :) [20:33:58] Since I haven't actually used it in anger, I probably shouldn't have a knee-jerk negative reaction to it. [20:34:28] Bleh, build systems that require I build and install the build system before I can build software... [20:35:47] I have a similar reaction to the suggestion that we should be distributing visual studio build environments. Which visual studio do we want to support? Why do we want to tie ourselves to a product that must be purchased when the compilers and other tools are now available for free as part of the SDK/WDK packages? [20:36:09] Was that part of that same thread? [20:36:13] yes [20:36:47] if you are building system software I think you should be capable of building from a command line [20:36:48] I looked at that and thought the whole thing looked like one of those discussions that was unlikely to actually go anywhere -- too much enthusiasm without knowledge of the problem. But I could be wrong. I'm somewhat ignoring it on that basis, though. [20:37:15] I'm focused on trying to make rx fast. I don't have time for meta discussions at the moment [20:37:22] I think what we've got right now is something we could evolve into something that works well. We tried ripping it out and replacing it long ago (with Automake) and never finished, and I don't really want to do that again. I'd rather do something incremental. [20:37:43] Also, yeah, our build system is not the worst of our problems, and ripping out and replacing the build system is going to be hugely disruptive. [20:37:52] We have enough disruptive changes in progress already. [20:38:21] --- meffie has left [20:38:25] --- ksumner has left [20:39:14] --- ksumner has become available [20:42:29] what is preventing us from increasing the window size at the moment is the fact that our algorithms rely on queue scans. A queue will hold a window size worth of packets for each call on the sender and receiver. As we increase the window size the time spent scanning the queues while holding sensitive locks increases. We need to store the data we require in another format as opposed to scanning queues each time we have a question to answer. [20:42:45] I'm just not sure we should be making such a change before 1.6 [20:48:21] --- meffie has become available [21:34:25] i have used cmake in anger [21:34:40] What do you think of it? [21:34:54] it's... another tool to install [21:36:30] * Russ hehs. [21:37:27] let me put it this way. i won't scream if people say "let's go there" but i won't be enthusiastic. i wil learn it and work with it. [21:40:38] Does it also solve our shared library construction issues, or does it still need either libtool or our current hand-rolled stuff? [21:41:54] i *think* it solves it. i don't promise i am right [21:44:40] * Russ sometimes thinks that libtool gets more bad press because it's used more, so people have found more edge cases to break it, so tends to be skeptical of anything else that claims to fix more cases but that almost no one uses. Seems more likely to me that they just haven't run into the edge cases yet. But it *would* be nice to have something that isn't a giant unmaintainable shell script to build shared libraries. [21:45:22] several tiny shell scripts [21:45:44] No, I mean libtool there. Our stuff is a lot simpler. [21:46:04] i know. i am suggesting replacing it with ... [21:46:07] My worry with our stuff is more that I'm not sure it's *correct*. We haven't put much weight on it yet.