peformance is not an issue, but only if there really are other FSM
threads that need execution time also.
- In packet processing do not use SILC_FSM_WAIT ever, since in current
- design all packets are processed in one FSM thread, and if one packet
- processor puts it into wait state, not other packets are received
- in the mean time. Instead go back to silc_client_connection_st_packet
- with SILC_FSM_CONTINUE, and then in the async function's callback
- set the old SilcPacket to the packet thread's state context and move back
- to the packet processor with silc_fsm_next and silc_fsm_continue_sync
- (always synchronously, never async). This design may change later,
- but for now this is it.
-
When to use FSM semaphore signalling?
The call cannot fail. Semaphores need not be uninitialized and the same
context may be reused.
+
+Finishing threads when closing connection
+
+ When closing SilcClientConnection all threads must first be finished
+ before the connection machine is finished. This is done by finishing
+ all running command threads. That will also finish all waiting packet
+ threads as they are always waiting for a command. If any thread is
+ waiting for something else than a command (such as event threads) they
+ must be explicitly finished. The threads are finished by continuing
+ them synchronously. The threads will detect that we are disconnected
+ (see below). SILC_FSM_YIELD must be returned in st_close() as that
+ gives the FSM scheduler time to finish the threads first. After that
+ the machine can be finished.
+
+ Also, any thread that runs in SilcClientConnection machine must always
+ after returning from wait state to check if we are disconnected by doing
+
+ if (conn->internal->disconnected)
+ xxx;
+
+ If disconnected the thread must finish immediately by returning
+ SILC_FSM_FINISH.
+
projects / silc.git / blobdiff