[erlang-questions] : : : : : : sctp_peeloff() support in OTP
Thu Apr 23 14:40:07 CEST 2009
On Thu, Apr 23, 2009 at 02:08:45PM +0200, Hynek Vychodil wrote:
> can you please use some mail client that supports threading? It's fourth
> thread about "sctp_peeloff() support in OTP".
> Best regards
Well, at least my mail client supports its own mail threading;
I have only two threads. One singelton message is Valentin Mimic's
that it did not manage to sort out. The others are fine.
I use User-Agent: Mutt/1.5.9i. It has been around very long
and works finefor me. As you see it supplies both In-Reply-To:
and References: headers, and gmail as you use is mostly
very good at tracking threads.
It is strange that you are experiencing problems.
> On Thu, Apr 23, 2009 at 11:56 AM, Raimo Niskanen <
> > wrote:
> > On Wed, Apr 22, 2009 at 10:37:21PM +0200, Valentin Micic wrote:
> > > > In what way is it useful to dispatch messages from the
> > > > driver level onto a PID dedicated for a streams if
> > > > you do not get flow control per stream?
> > >
> > > Not sure if it would be useful, and not sure if that is what I've been
> > > trying to say/ask. Forget about my "stream processor" (*) suggestion, it
> > is
> > > irrelevant, and I prefer the implementation at the driver level anyway.
> > > I was only wondering if there is a way to achieve a stream separation
> > > without utilizing additional file descriptors. I think yes, but the
> > driver
> > > may end up too complex and difficult to maintain, etc.
> > If it is useful it may be worth the complexification...
> > But I am now under the assumption that a stream separation
> > that does not utilize additional file descriptors
> > (as you ask for) can not do per-stream flow control
> > (with respect to remote peer) and therefore is not useful.
> > Prove me wrong and I might do it.
> > > I would be very grateful if you implement this feature whichever way you
> > > find fit :-).
> > >
> > > BR
> > >
> > > V.
> > >
> > > (*) I did say that stream processor can do queuing, though. This would
> > imply
> > > some basic flow control vis-à-vis target PID, but not necessarily with
> > > respect to remote peer. :-)
> > >
> > --
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> > _______________________________________________
> > erlang-questions mailing list
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> --Hynek (Pichi) Vychodil
> Analyze your data in minutes. Share your insights instantly. Thrill your
> boss. Be a data hero!
> Try Good Data now for free: www.gooddata.com
> erlang-questions mailing list
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions