> > I thought if I configure and compile pen --with-poll, select() would
not
> > be used and poll() would be used instead?
>
> The poll() code is experimental, as in "probably doesn't work
properly".
What does that mean? Is poll() used when compiling with --with-poll ?
Are there known instabilities will poll() ? Or has there just not been
enough testing?
Can I understand from this that you do not recommend using pen with
poll() in a productive environment to anyone?
> I've considered tossing it out because it doesn't actually solve the
> problems it was supposed to, due to the performance problems you note
> below.
It's surely a lot better than select(), as far as I know. I don't know
which performance measures you have made. All my knowledge is based upon
theory and from that website I mentioned. From what I've seen so far,
poll() should make a huge difference to select(). Isn't that so?
> There is however no completely portable way to do that.
Well, if poll() worked fine and someone made kqueue() as compilation
option I would regard this as portable. OK, you cannot use kqueue on
Linux, but that's not pens fault, so configure should return an error if
--with-kqueue would be selected on a Linux-machine. It would be portable
on all machines that support kqueue(). :-)
> An alternative would be to get at the raw frames (ip or ethernet)
instead.
> It would also
> require a major rewrite of the low-level plumbing in pen. On the other
> hand, it would be easier to do things, such as modifying frame
headers. It
> is difficult to say what it would do to performance, although I
believe it
> would be very fast.
Yes, maybe, but why reinventing the wheel again. Kqueue should not be
too hard to implement and then you have it. Even raw coding would not
provide a much better performance than kqueue, besides, that's even not
necessary at all, because kqueue performs perfectly. In my eyes I
wouldn't recommend anyone with the need for a large number of
simultaneous connections to use Linux as OS. Those people should use a
BDS-system because of the kqueue advantage. That's it. On Linux even
/dev/poll is in experimental state. I cannot see a sense in trying to
make a tool as portable as possible, while some OS limitations just make
it unusable for certain purposes on certain OSs.
Furthermore, implementing a way to do this the "raw way" would probably
result in problems regarding portability, too. I guess the amount of
time to spend into the raw way would be much higher, too.
Can't you imagine to use kqueue?
You're pretty much into Linux, aren't you? :-)
> Ulric
Regards,
Torsten
This archive was generated by hypermail 2.1.2 : Wed Sep 18 2002 - 13:02:52 CEST