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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 08 January 2017 01:16 UTC

To: Anima signaling DT <anima-signaling@ietf.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <66f4d2f6-d22a-edd7-5514-0482aaf48277@gmail.com>
Date: Sun, 08 Jan 2017 14:16:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/7DpRwaXa7aeSOcqR8T0Drqv_dzs>
Cc: draft-liu-anima-grasp-api@ietf.org
Subject: [Anima-signaling] GRASP API issue 1: non-threaded ASAs
Precedence: list

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

[Anima-signaling] GRASP API issue 1: non-threaded… Brian E Carpenter