Hi Christian:
>And now especially on the select theme:
Okay, a small note: the select in Go is not the same as
the select() in the BSD Socket library (because we have had this
confusion previously in the mailing list). For a moment, let us use
descriptor to cover both sockets and channels. Conceptually, the BSD
select() tells the invoker which descriptors are ready. It is up to the
invoker to actually perform an action. The Go select actually
performs the action on the descriptor and tells the invoker what
action was taken.
>I talked to M.v.Löwis about blocking I/O and select
>in Stackless. He had quite convincing
>arguments that this stuff should get a dedicated worker thread,
>with blocking selects that get woken up by the system.
>All poll-like approaches seem to be inferior and work only
>well because we have TCP/IP.
>But in UDP we would be missing packets. That rang a bell in me,
>this can not be the right way.
I guess at the end of the day if UDP packets (or any message)
come in faster than one's ability to process them, either they will
queue up (if you have a buffer) or packets will be dropped. Hopefully
one has a robust protocol built on the UDP datagrams. But this isn't
really saying anything new.
I can speculate on this design. However I think it would be better to
experiment. We could set up a test where one locates the networking in a
separate OS thread and hit the system with UDP packets. Steadily raise the
inter-arrival rate of the packets and/or the number tasklets processing packets
and see what happens.
My suspicion is that much depends on whether most of the application's time is
spent doing CPU or IO intensive stuff.
Although when I first started using Stackless, I would use a separate thread to
run the networking, I don't have a good handle on how the stackless scheduler
handles channels that reside in different threads.
>I'd be interested to discuss this, as I am not a networking expert.
I am not an expert but I am interested in discussing and exploring this issue
because it is important (and fun).
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
