On Sat, Jan 16, 2010 at 3:21 PM, Pete Zaitcev <zaitcev@xxxxxxxxxx> wrote: > On Sat, 16 Jan 2010 13:38:26 -0800 > Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: > >> Shouldn't ncld_unlock and ncld_close return an error code rather than >> just eating all errors? The server certainly does sometimes send back >> error responses for these requests. > > This is an old bone of contention. The problem is, suppose the > application is cleaning up for exit. What is it supposed to do with > the error code? It cannot even retry sanely. If it's important enough for you to print out an error (*not* debug) message in the library, it should be important enough to pass along to the library user. After all, not everyone might be using a command-line app. Some people might want to see the error reflected in a dialog box, etc. >> The event() callback seems like to lead to some complexity. For >> example, let's say I have a "main" thread that does ncld_open, and >> then ncld_write. [] > > Indeed, it reopens the old problems somewhat. The plan is to see > how ncld matches tabled and chunkd and perhaps tweak the API a bit. > >> I guess the main thread could check an atomic variable before each >> ncldc operation (has_failed? is_gone?) Or a mutex-protected variable. > > That's pretty much what I expect from most command-line tools. > The check is implicit in read/write/lock operations. The check is built-into the library? That makes sense. Also, shouldn't the check also be implicit in unlock and close? Another reason for them to return an error code. :) >> Rather than the event callback, I almost feel like it would be better >> just to have an ncldc_poll function modelled on poll(). [] > > If we do that, we're at the square 1 with respect to complexity > reduction in a multi-thread environments. If someone wants that, > they may continue to use cldc_foo. > > As a reminder, my aim here is 2-fold: > > 1. Provide something that permits to use synchronous programming in > cldu.c. I am having a big trouble modifying it, and I know that > when we support slave mode, I'll need even more complex behaviour > from it. It will crash on itself unless I implement ncld. > > 2. Make something that lures new contributors into a sense of simplicity. > We keep saying that it's almost like a filesystem, only not quite > POSIX. But the actual API is such that nobody will use it if he > has an alternative. We need a pseudo-filesystem API to continue > making these claims with a straight face. I think this is a reasonable API. It's nice to see a more familiar face on read, write, etc. I was just trying to point out another path, one you might not have thought of. Colin -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
