Looks promising... 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. 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. But sometime after the ncld_open succeeds, the session goes away. This triggers the event() callback to happen in the context of the "extra thread." Now, somehow, the "extra" thread needs to notify the "main" thread that something has happened, the jig is up, and it's time to go back to square one and reopen the session. (choose your favorite metaphor.) I guess the main thread could check an atomic variable before each ncldc operation (has_failed? is_gone?) Or a mutex-protected variable. Or you could just let the "main" thread continue to blunder on until it crashes into an error code, then check has_failed. (In this case, you obviously need to ensure that all the pointers that it's using, like the session pointer, continue to be valid until that point.) None of these options really seem satisfying. Rather than the event callback, I almost feel like it would be better just to have an ncldc_poll function modelled on poll(). It would block until the previous operation either completed or failed, or some other event happened. This implies that the rest of the operations are nonblocking. You have to have a state machine in your program anyway-- you might as well keep it simple and all in one place. What do you guys think? regards, Colin On Fri, Jan 15, 2010 at 10:53 PM, Pete Zaitcev <zaitcev@xxxxxxxxxx> wrote: > On Fri, 15 Jan 2010 18:40:44 -0800 > Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: > >> 1) when starting the cld session, the user code could register a >> "vtable" containing a bunch of different callbacks. >> That way all GET responses for the session could flow through >> my_get_response(), and so on. > > I'm not sure if that would be much better than what we have now, > so I don't see a big pay-off from switching to it. > >> I think a non-blocking API, in some form, should probably be >> available, though, in case people need it. We may not be able to >> anticipate all the uses that CLD is put to. > > The easiest way to do this is to leave cldc intact. > >> 2) provide a blocking API that users could take advantage of. >> I think for a lot of simple programs, programmers would be happy to >> spawn a thread per CLD session. In fact, I'm not aware of any programs >> that want to spawn a lot of cld sessions (maybe someone can point out >> one.) > > Here's what I have for tonight: > -- 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
