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.
> 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.
> 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.
Anything else is not a goal, at least thus far. And actually I am
going to resist expanding ncld's scope too much and ruining the
simplicity of the model. You want async, use cldc.
-- Pete
--
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
