diff options
authorIOhannes m zmölnig <zmoelnig@users.sourceforge.net>2013-04-11 13:17:44 +0000
committerIOhannes m zmölnig <zmoelnig@users.sourceforge.net>2013-04-11 13:17:44 +0000
commit56e81faa4c4f7025e31a18d7e8fed2f01e77a471 (patch)
parent312049fec0714ecfa0dccca36976571df2eb047a (diff)
added notes
svn path=/trunk/externals/iem/iemnet/; revision=17085
1 files changed, 15 insertions, 14 deletions
diff --git a/NOTES.txt b/NOTES.txt
index da5ee7a..9e5becd 100644
--- a/NOTES.txt
+++ b/NOTES.txt
@@ -3,20 +3,13 @@ scratchpad for the development of iemnet
speed & syslocks
-one bottleneck right now is the synchronisation with Pd's
-main thread to register a clock callback.
-doing a sys_lock() whenever a package arrives will slow down things immensely.
- no sys_lock(): will eventually crash Pd (no option)
- use sys_trylock(): this might eventually fail to notify Pd of newly arrived
- packets (bad for throughput)
- external polling: no syslock needed at all, but more complicated
- keep track of clock_callback: "notified" flag tells us, whether we have already
- sent a notification which has not yet been handled...no need to notify again
- #4 looks most promising
+setting Pd's clocks is not thread-safe, but calling sys_lock() will slow
+the entire process down to unusability.
+therefore, we use a (per-receiver) thread, that get's waits on a pthread_cond_t
+and will syslock if needed.
+LATER there should only be one of these clock-threads (per RTE, in case we
+finally can run multiple Pd's in a single applications), that maintains it's own
+list of callbacks+data.
tests for tcpclient/server:
client disconnects -> server should get notified
@@ -24,3 +17,11 @@ tests for tcpclient/server:
client crashes -> server should disconnect
server crashes -> client should disconnect
+known BUGS:
+[tcpclient] now does all the actual connect/disconnect work in a helper-thread.
+unfortunately, iemnet__receiver_destroy() assumes that it is called from the
+main-thread and will outlet_list the remaining bytes in the dtor.
+however, outlet_list is not threadsafe.
+possible solution: see speed&syslocks for a leightweight thread-safe callback