diff options
author | IOhannes m zmölnig <zmoelnig@users.sourceforge.net> | 2013-04-11 13:17:44 +0000 |
---|---|---|
committer | IOhannes m zmölnig <zmoelnig@users.sourceforge.net> | 2013-04-11 13:17:44 +0000 |
commit | 56e81faa4c4f7025e31a18d7e8fed2f01e77a471 (patch) | |
tree | 83c4245964af9cb448bab390b6095cc99d5b1c83 | |
parent | 312049fec0714ecfa0dccca36976571df2eb047a (diff) |
added notes
svn path=/trunk/externals/iem/iemnet/; revision=17085
-rw-r--r-- | NOTES.txt | 29 |
1 files changed, 15 insertions, 14 deletions
@@ -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. |