> -----Original Message-----
> From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
>
> > I don't agree here - I personally don't like threads all
> that much: they have their purposes, but using a new thread
> whenever you need a new context is not a good choise,
> especially if both threads need to do IO on the same socket :
> major problems. we just need better logic handling the
> "sleep" period of the SMPP throttling.
>
> agreed here Oded, that more threads for the same socket, more problems
> hay arrise. Maybe a reformulation of the logic would help in first and
> then we may think about getting an own thread for the enquire_link
> that is safe enough in the wild.
I don't see why there is need for another thread - at all. the SMSC is speaking to a
single entity - it should not deal with a distributed logic: think about the most
basic problem : thread A sends a packet, SMSC receives packet and sends response ,
thread B eats packet - don't know what to do with it, throws it away, thread A times
out on waiting for response.
So, you should have a shared buffer where both threads read from the socket and store
to the buffer (in which case you will need to lock the socket from before the read
till after the store - other wise you'll have sync problems). both threads will look
in the buffer for the packets they need and extract the packet from the shared buffer(
of course you'll need to lock every read and every write), sending the response back
down the socket (which will need locking again).
Ok, better solution. have a third thread to read and write from/to the socket, parsing
packets and storing them in an incoming "event queue". the two threads will simply
poll on the list, each getting only the packets they need, process and store a
response in an outgoing queue which the socket thread will eat and send down the line.
yes - looks to be working.
of course, in all cases everything but the actual packet processing (which is always
two orders of magnitude faster then the network) have to be serialized, in which case
you gain nothing from the distinction, except losing information at each part of the
logic (or making it more difficult to handle the shared information).
How about this : dump the threads idea, and just have a flag that says something like
"don't send anything now except enquire link packets", and have the sending functions
consult that flag before doing anything ?
My vote is for the KISS solution.
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
It's Only Forever, not long at all, lost and lonely. No one can blame you for walking
away.
Too much rejection, no love injection. Life can be easy, it's not always swell.
Don't tell me truth hurts little girl, cause it hurts like hell. But down in the
Underground you'll find someone true.
Down in the Underground a land serene, a crystal moon... It's only forever, it's not
long at all.
Lost and lonely that's Underground, Underground....
-- David Bowie / Underground
