X-Git-Url: http://git.silcnet.org/gitweb/?a=blobdiff_plain;f=lib%2Fsilcclient%2FREADME;h=66a14e7d072148aa85b4744ca57376063a251623;hb=dba72cd444469151d0def91ec67361c68ee78022;hp=a9c9d485bf64d21034f256db6f7d59e788607944;hpb=6caeb1c499fe1ab80aaa24b1a35c89b91c57b7cf;p=silc.git

diff --git a/lib/silcclient/README b/lib/silcclient/README
index a9c9d485..66a14e7d 100644
--- 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.
 
-   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?