changeset 1551:5175bed443f9

Warn about concurrency issues with message-passing
author Adam Chlipala <adam@chlipala.net>
date Sun, 28 Aug 2011 14:43:30 -0400
parents daf71c76707e
children c3b5cf5c2f98
files doc/manual.tex src/c/urweb.c
diffstat 2 files changed, 4 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- a/doc/manual.tex	Sun Aug 28 14:01:41 2011 -0400
+++ b/doc/manual.tex	Sun Aug 28 14:43:30 2011 -0400
@@ -2033,6 +2033,8 @@
 
 Clients and channels live only as long as the web browser page views that they are associated with.  When a user surfs away, his client and its channels will be garbage-collected, after that user is not heard from for the timeout period.  Garbage collection deletes any database row that contains a client or channel directly.  Any reference to one of these types inside an $\mt{option}$ is set to $\mt{None}$ instead.  Both kinds of handling have the flavor of weak pointers, and that is a useful way to think about clients and channels in the database.
 
+\emph{Note}: Currently, there are known concurrency issues with multi-threaded applications that employ message-passing on top of database engines that don't support true serializable transactions.  Postgres 9.1 is the only supported engine that does this properly.
+
 
 \section{Ur/Web Syntax Extensions}
 
--- a/src/c/urweb.c	Sun Aug 28 14:01:41 2011 -0400
+++ b/src/c/urweb.c	Sun Aug 28 14:43:30 2011 -0400
@@ -220,7 +220,6 @@
   pthread_mutex_lock(&c->lock);
   --c->refcount;
   pthread_mutex_unlock(&c->lock);
-
 }
 
 static const char begin_msgs[] = "Content-type: text/plain\r\n\r\n";
@@ -3185,7 +3184,8 @@
     delta *d = &ctx->deltas[i];
     client *c = find_client(d->client);
 
-    assert (c != NULL && c->mode == USED);
+    assert (c != NULL);
+    assert(c->mode == USED);
 
     client_send(c, &d->msgs, ctx->script.start, uw_buffer_used(&ctx->script));
   }