diff options
| -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. |