[OTR-dev] Re: Requirements for libotr4

[Ian Goldberg]

See what happens when I post too early in the morning?  ;-)

On Sat, Jun 21, 2008 at 09:42:10AM -0400, Ian Goldberg wrote:
>  /* Call this from the main thread only.  call_when_ready will be called
>   * in the main thread. */
>  gcry_error_t otrl_privkey_generate_start(OtrlUserState us,
>      const char *accountname, const char *protocol,
>      void (*call_when_ready)(void *newkey, void *data), void *data);
> 
>  /* You can call this from a different thread.  call_when_done will be
>   * called in the different thread. */
>  gcry_error_t otrl_privkey_generate_calculate(void *newkey,
>      void (*call_when_done)(void *newkey, void *data), void *data);
> 
>  /* Call this from the main thread only. */
>  gcry_error_t otrl_privkey_generate_finish(OtrlUserState us,
>      void *newkey, FILE *fp);

With the specified division of threads, the callbacks are now
unnecessary.

  /* Call this from the main thread only.  It will set *newkeyp, and
   * then you can spawn a new thread if you wish, and call
   * otrl_privkey_generate_calculate. */
  gcry_error_t otrl_privkey_generate_start(OtrlUserState us,
      const char *accountname, const char *protocol,
      void **newkeyp);
 
  /* You can call this from a different thread.  When it completes, call
   * otrl_privkey_generate_finish from the _main_ thread. */
  gcry_error_t otrl_privkey_generate_calculate(void *newkey);
 
  /* Call this from the main thread only. */
  gcry_error_t otrl_privkey_generate_finish(OtrlUserState us,
      void *newkey, FILE *fp);


But the questions about how to deal with keys autogenerated during the
AKE are still important:

> But I've got a question for you, Uli:  key generation usually happens
> when you get an incoming OTR Query or OTR Commit message.  If you spawn
> off a thread to generate the key, how will you keep around the state you
> need in order to remember to continue the AKE when you're done the key
> generation?  In some languages, call-with-current-completion would
> probably suffice, but otherwise it seems like a real pain.  In fact, I
> think libotr has to know this, since message.c will be the one that has
> to deal with this, since it calls ops->create_privkey.  If that routine
> spawns a thread to generate the key and return immediately, libotr will
> be very confused.
> 
> 
> So: even assuming we do the above, your create_privkey callback *must
> not* return until the key generation is complete.  You can still perform
> the key generation in a subthread, though, and your main thread can
> handle UI events to avoid appearing frozen, but it *must not* call
> any libotr functions (even in the UI handlers, hmm).
> 
> 
> Now what do you think?


   - Ian