Changeset d3a1ade3 in mainline

Timestamp:

2010-12-26T17:25:57Z (14 years ago)

Author:

Jiri Svoboda <jiri@…>

Branches:

lfn, master, serial, ticket/834-toolchain-update, topic/msim-upgrade, topic/simplify-dev-export

Children:

d1c041a

Parents:

d3cce52

Message:

'Exchange' is better than 'transaction', because it does not evoke ACID semantics (which we don't have).

Location:

uspace

Files:

• lib/c/generic/async_sess.c (modified) (4 diffs)
• lib/c/include/async_sess.h (modified) (1 diff)
• srv/vfs/vfs_register.c (modified) (2 diffs)

uspace/lib/c/generic/async_sess.c

@@ -37 +37 @@
  *
  * By the term 'session', we mean a logical data path between a client and a
- * server over which the client can perform multiple concurrent transactions.
- * Each transaction consists of one or more requests (IPC calls) which can
+ * server over which the client can perform multiple concurrent exchanges.
+ * Each exchange consists of one or more requests (IPC calls) which can
  * be potentially blocking.
  *
  * Clients and servers are naturally connected using IPC phones, thus an IPC
  * phone represents a session between a client and a server. In one
- * session, there can be many outstanding transactions. In the current
- * implementation each concurrent transaction takes place over a different
- * connection (there can be at most one active transaction per connection).
+ * session, there can be many outstanding exchanges. In the current
+ * implementation each concurrent exchanges takes place over a different
+ * connection (there can be at most one active exchage per connection).
  *
  * Sessions make it useful for a client or client API to support concurrent
@@ -55 +55 @@
  * There are several possible implementations of sessions. This implementation
  * uses additional phones to represent sessions. Using phones both for the
- * session and also for its transactions/connections has several advantages:
- *
- * - to make a series of transactions over a session, the client can continue to
+ * session and also for its exchages/connections has several advantages:
+ *
+ * - to make a series of exchanges over a session, the client can continue to
  *   use the existing async framework APIs
  * - the server supports sessions by the virtue of spawning a new connection
  *   fibril, just as it does for every new connection even without sessions
  * - the implementation is pretty straightforward; a very naive implementation
- *   would be to make each transaction using a fresh phone (that is what we
+ *   would be to make each exchage using a fresh phone (that is what we
  *   have done in the past); a slightly better approach would be to cache
- *   connections so that they can be reused by a later transaction within
+ *   connections so that they can be reused by a later exchange within
  *   the same session (that is what this implementation does)
  *
  * The main disadvantages of using phones to represent sessions are:
  *
- * - if there are too many transactions (even cached ones), the task may hit its
+ * - if there are too many exchanges (even cached ones), the task may hit its
  *   limit on the maximum number of connected phones, which could prevent the
  *   task from making new IPC connections to other tasks
  * - if there are too many IPC connections already, it may be impossible to
- *   create a transaction by connecting a new phone thanks to the task's limit on
+ *   create an exchange by connecting a new phone thanks to the task's limit on
  *   the maximum number of connected phones
  *
@@ -157 +157 @@
 }
 
-/** Start new transaction in a session.
+/** Start new exchange in a session.
  *
  * @param sess_phone    Session.
- * @return              Phone representing the new transaction or a negative error
+ * @return              Phone representing the new exchange or a negative error
  *                      code.
  */
-int async_transaction_begin(async_sess_t *sess)
+int async_exchange_begin(async_sess_t *sess)
 {
         conn_node_t *conn;
@@ -219 +219 @@
 }
 
-/** Finish a transaction.
+/** Finish an exchange.
  *
  * @param sess          Session.
- * @param data_phone    Phone representing the transaction within the session.
- */
-void async_transaction_end(async_sess_t *sess, int data_phone)
+ * @param data_phone    Phone representing the exchange within the session.
+ */
+void async_exchange_end(async_sess_t *sess, int data_phone)
 {
         conn_node_t *conn;

uspace/lib/c/include/async_sess.h

@@ -46 +46 @@
 extern void async_session_create(async_sess_t *, int);
 extern void async_session_destroy(async_sess_t *);
-extern int async_transaction_begin(async_sess_t *);
-extern void async_transaction_end(async_sess_t *, int);
+extern int async_exchange_begin(async_sess_t *);
+extern void async_exchange_end(async_sess_t *, int);
 
 #endif

uspace/srv/vfs/vfs_register.c

@@ -274 +274 @@
                 if (fs->fs_handle == handle) {
                         fibril_mutex_unlock(&fs_head_lock);
-                        phone = async_transaction_begin(&fs->session);
+                        phone = async_exchange_begin(&fs->session);
 
                         assert(phone > 0);
@@ -298 +298 @@
                 if (fs->fs_handle == handle) {
                         fibril_mutex_unlock(&fs_head_lock);
-                        async_transaction_end(&fs->session, phone);
+                        async_exchange_end(&fs->session, phone);
                         return;
                 }