Client library rewrites.

[silc.git] / lib / silcclient / README

diff --git a/lib/silcclient/README b/lib/silcclient/README
index a9c9d485bf64d21034f256db6f7d59e788607944..66a14e7d072148aa85b4744ca57376063a251623 100644 (file)
--- a/lib/silcclient/README
+++ b/lib/silcclient/README
@@ -53,16 +53,6 @@ Using FSM
    peformance is not an issue, but only if there really are other FSM
    threads that need execution time also.
 
    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?
 
 
 When to use FSM semaphore signalling?