socket limitations question [TCL]

Prev: Announce: Runtime Library 3.0 Gestalt Items 1.1 and Hugelist 1.4,Tcl-Mode for XCode
Next: http::geturl intermittent hang - looks for ideas...

From: tom.rmadilo on 10 Nov 2009 19:58

On Nov 10, 4:15 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Nov 10, 11:38 pm, phil <pedi...(a)west.com> wrote:
>
>
>
> > poll() is also a lot more efficient than select().
> > One can preallocate the "pollfd array" ONCE and reuse it over and
> > over.
> > Unlike select() where you generally make FD_Sets over from scratch or
> > memcpy it back...
>
> Yes but you still have to iterate over the whole array to find the hot
> ones, so it's O(N).
> Only epoll() is O(1) in that it picks them out for you (and doesn't
> iterate under the hood either; they are "pushed" by the kernel instead
> of being "pulled" by the caller.)

I think the basic problem with this reasoning is that you assume a
single choke-point. This has to do with not using threads (or other
application features) to divide the work. So a simple system which
must run everything through one "select" is going to run into
problems. This solution ignores many other opportunities for handling
increased load. Even within a single thread, you could move fds into
different sets, kind of like a queue of sets. This helps more than you
think. You process new fds and push them to the next set, then you
process the next set, etc. The result is that responsive fds move very
quickly through the queue and slow fds tend to wait. If you use
threads, then the fd gets moved to a set of one.

But scalability potential is not limited by one particular syscall.
You might have to create an larger architecture, but this usually
allows benefits beyond the fd choke-point problem...like running
specific code based upon the current state.

But epoll seems great for a dumb and dirty scalability issue. It isn't
as powerful as a divide-and-conquer solution.

From: Donal K. Fellows on 11 Nov 2009 05:36

On 10 Nov, 22:38, phil <pedi...(a)west.com> wrote:
> poll() can support > 1024 fds and is quite portable -- well before
> 1995.
>
> poll() is also a lot more efficient than select().

Not on all platforms. I've seen systems where poll() was implemented
on top of select() though I forget which; I just remember seeing that
in stack traces of various programs I was working on. Because of this,
which low-level API to build the Tcl Notifier on top of has to be a
configuration option (select is a LCD, but it is widely available)
*and* someone has to actually submit an implementation...

Donal.

From: Tomas Friml on 11 Nov 2009 15:52

On Nov 11, 11:07 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Nov 10, 10:57 pm, Tomas Friml <instantni....(a)gmail.com> wrote:
>
>
>
> > On Oct 15, 2:48 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > wrote:
>
> > > On Oct 14, 3:30 pm, "Donal K. Fellows"
>
> > > <donal.k.fell...(a)manchester.ac.uk> wrote:
> > > > On 14 Oct, 01:41, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > > > wrote:
>
> > > > > However, as a recent discussion on tclcore showed, there is another
> > > > > one that kicks in, and that is not configurable at runtime:
> > > > > FD_SETSIZE, which is the static size of the bit arrays passed to select.
> > > > > IIRC it is 1024 for glibc.
>
> > > > On at least some OSes, you can set it at build-time.
>
> > > Yes. Recompile your libc, reboot, and pray.
>
> > > -Alex
>
> > Hi, I recently hit this same problem described here, after sock1024 is
> > used thesocketcommand basically stops working. I was trying to find
> > out what need to do get it working for more than 1024 sockets but I
> > don't really understand the exact relation between tcl and libc (I'm
> > tcl newbie). How do I find out which libc my tcl uses?
>
> Well, it uses _the_ libc present on the system (unless you're
> intentionally juggling with several versions, you have just one of
> them). Then look at the value of the FD_SETSIZE in the associated
> include files.
>
> -Alex

Thanks Alex, I recompiled the libc (setting FD_SETSIZE to 10000 for a
start), updated, restarted, but it didn't help :(. Still the same...

From: Alexandre Ferrieux on 11 Nov 2009 18:28

On Nov 11, 9:52 pm, Tomas Friml <instantni....(a)gmail.com> wrote:
> On Nov 11, 11:07 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> wrote:
>
>
>
>
>
> > On Nov 10, 10:57 pm, Tomas Friml <instantni....(a)gmail.com> wrote:
>
> > > On Oct 15, 2:48 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > > wrote:
>
> > > > On Oct 14, 3:30 pm, "Donal K. Fellows"
>
> > > > <donal.k.fell...(a)manchester.ac.uk> wrote:
> > > > > On 14 Oct, 01:41, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > > > > wrote:
>
> > > > > > However, as a recent discussion on tclcore showed, there is another
> > > > > > one that kicks in, and that is not configurable at runtime:
> > > > > > FD_SETSIZE, which is the static size of the bit arrays passed to select.
> > > > > > IIRC it is 1024 for glibc.
>
> > > > > On at least some OSes, you can set it at build-time.
>
> > > > Yes. Recompile your libc, reboot, and pray.
>
> > > > -Alex
>
> > > Hi, I recently hit this same problem described here, after sock1024 is
> > > used thesocketcommand basically stops working. I was trying to find
> > > out what need to do get it working for more than 1024 sockets but I
> > > don't really understand the exact relation between tcl and libc (I'm
> > > tcl newbie). How do I find out which libc my tcl uses?
>
> > Well, it uses _the_ libc present on the system (unless you're
> > intentionally juggling with several versions, you have just one of
> > them). Then look at the value of the FD_SETSIZE in the associated
> > include files.
>
> > -Alex
>
> Thanks Alex, I recompiled the libc (setting FD_SETSIZE to 10000 for a
> start), updated, restarted, but it didn't help :(. Still the same...

Well, the kernel has some influence too ;-) If select is a syscall
(instead of being

From: Alexandre Ferrieux on 11 Nov 2009 18:31

First | Prev | Next | Last
Pages: 1 2 3 4 5
Prev: Announce: Runtime Library 3.0 Gestalt Items 1.1 and Hugelist 1.4,Tcl-Mode for XCode
Next: http::geturl intermittent hang - looks for ideas...