[vwnc] Non-Blocking Sockets Help... Please Anyone.....

Hi everyone

We are developing SNMP management application  and We need a way to have a non blocking socket to start that continuously listens on a specific port.

Currently we use the code blow and we are trying to get the same functionality using non-blocking sockets. If anyone have any information regarding can you please let us know. Thanks.
    socketServer := SocketAccessor newUDPserverAtPort: PORT.
    socketServer readWait.




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Kalaimathan,

On Mar 5, 2008, at 3:04 AM, Kalaimathan Mahenthiran wrote:

The simplest thing to do is to #fork your socket reading code so it  
runs in a separate Process, it can communicate with your main Process  
using a SharedQueue. The main process can poll the SharedQueue without  
blocking by using #peek or #nextAvailable.


In TCP applications it is quite common to have both the reading code  
and the writing code each run in its own process, separate from the  
main program. I guess with UDP it is ok to have the writing code in  
the main process, you can decide that based on either performance or  
aesthetics (but that's just a guess, my experience is with TCP).




I have a question for the others on the list: what is the difference  
between SharedQueue's #peek and #nextAvailable?




R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck wrote:
> I have a question for the others on the list: what is the difference  
> between SharedQueue's #peek and #nextAvailable?

It looks like SharedQueue>>peek answers the next available object on the
queue, but does not remove it. If there is no object available, does not
wait, but answers nil.

EventQueue>>nextAvailable is similar, but if it returns a non-nil, it
has removed it from the queue.


I also notice that there appears to be a flaw in the implementation of
EventQueue.

Say process p1 is in #nextAvailable. It has acquired the system-wide
#valueUninterruptably semaphore, and the EventQueue's accessProtect. It
has found that readSynch's excessSignals = 1, so is just about to wait
on readSynch.

If higher-priority Process p2 preempts at this point, and p2 sends #next
to this EventQueue, p2 will wait on readSynch, consuming the signal
there. p2 will then wait on the system-wide #valueUninterruptably
semaphore, which is held by p1. Since p2 cannot proceed, p1 runs. p1
waits on readSynch, which at this point has no excess signals. So p1
cannot proceed.

p1 and p2 are deadlocked until some other Process signals readSynch. But
every single method that could signal readSynch will first wait on
either the accessProtect or the system-wide #valueUninterruptably
semaphore, both of which are held by p1. So any other Process that tries
to read or write the queue will be blocked.

It's slightly tricky to fix this, but I believe it can be done.

Regards,

-Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc