Re: Re: Efficient non-blocking UDP server

I would be surprised if Thread::Queue would have the performance needed for handling hundreds of UDP packets.

If you realise that a shared array (to which Thread::Queue is a very simple frontend) stores its valus both in the current thread as well as in the hidden background thread. Not very performance friendly.

If you want to try Thread::Queue for this application, make sure that you have Perl 5.8.1 or higher, as 5.8.0 has a severe memory leak with shared arrays.

Liz

Comment on Re: Re: Efficient non-blocking UDP server

Replies are listed 'Best First'.
Re: Re: Re: Efficient non-blocking UDP server by calin (Deacon) on Mar 21, 2004 at 19:19 UTC
liz, thanks for feedback. I didn't realize Tread::Queue could be so costly ; my suggestion was the result of a mere query on CPAN by the word queue ; the module looked interesting. There's another thing: I suppose the OP requires hundreds of packets per second as a burst condition, right? The perspective of coping with a sustained condition like that, I mean receiving and processing that amount in pure Perl, in real time, looks dim. Even if the receiving routine is fast enough, the queue would quickly fill up. (there's a discussion on what the "processing" amounts to). Anyway, that calls for optimized C code, IMHO. All in all, I think the main idea of my original reply (treat your network code as an interrupt handling routine) is still valid in the context of datagram protocols.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Efficient non-blocking UDP server
by calin (Deacon) on Mar 21, 2004 at 19:19 UTC

liz, thanks for feedback. I didn't realize Tread::Queue could be so costly ; my suggestion was the result of a mere query on CPAN by the word queue ; the module looked interesting.

There's another thing: I suppose the OP requires hundreds of packets per second as a burst condition, right? The perspective of coping with a sustained condition like that, I mean receiving and processing that amount in pure Perl, in real time, looks dim. Even if the receiving routine is fast enough, the queue would quickly fill up. (there's a discussion on what the "processing" amounts to). Anyway, that calls for optimized C code, IMHO.

All in all, I think the main idea of my original reply (treat your network code as an interrupt handling routine) is still valid in the context of datagram protocols.

[reply]