From 56e81faa4c4f7025e31a18d7e8fed2f01e77a471 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?IOhannes=20m=20zm=C3=B6lnig?= Date: Thu, 11 Apr 2013 13:17:44 +0000 Subject: added notes svn path=/trunk/externals/iem/iemnet/; revision=17085 --- NOTES.txt | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) (limited to 'NOTES.txt') 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. - -alternatives: - 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 +framework. -- cgit v1.2.1