Subject: [Anima-signaling] GRASP API issue 1: non-threaded ASAs

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Jan 2017 14:16:22 +1300

Hi,

While investigating a C representation of the GRASP API, we have
hit this question: What if there is no real multithreading support
in the language/operating system used to write an ASA?

A typical way to solve that problem is to use an event-loop or polling
style of implementation - which basically requires the GRASP function
calls to be non-blocking.

There are 5 API calls that work well in a multi-threaded solution but
would cause problems in an event-loop solution:

discover()
request_negotiate()
negotiate_step()
synchronize()

  These may wait until a timeout expires.

listen_negotiate()

  This blocks until an incoming request_negotiate() arrives.

A possible solution is to provide non-blocking versions of each of
this, which return immediately with a return code meaning "not yet"
until they have a result (or a timeout). A threaded implementation
would use the normal, blocking versions; an event-loop implementation
would use the non-blocking versions.

Comments? Other suggestions?

   Brian