<div dir="ltr">Since we're talking about the HttpListener..    Any thoughts on making HttpListener more friendly to longer running, blocked tasks.?   Such as Event Queues.   Almost all of these edge cases involve reading the input stream for paths/queryparams/etc, blocking the thread while doing some work or waiting some amount of time, then servicing the response.   With the current HTTPListener this leads to lots of precious threadpool threads blocked and not doing anything but also counting against the mono threadpool thread limit.  The simplest way that this can be done is simply decoupling the HttpListener threads from the threadpool thread limit..  that way the threadpool threads are limited separately.     The more complicated way could be to allow some sort of thread sleep call that puts the IO streams for the http requests into a pool of streams managed by a single worker thread while they're waiting and then restores them to it's own thread once the work is done to send the response.   I have previously done the second method with a third party HttpListener replacement and it saved a lot of threads which freed them up to do other useful things in a highly parallel server without forcing the end user to manually specify a larger mono maximum threadpool thread limit.<div><br></div><div>Regards</div><div><br></div><div>Teravus</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 19, 2015 at 2:28 PM, Greg Young <span dir="ltr"><<a href="mailto:gregoryyoung1@gmail.com" target="_blank">gregoryyoung1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes exactly my intention. The problem is I am only given http prefixes<br>
in that code.<br>
<br>
Consider the case I have an interface 192.168.1.1 and an interface 10.114.1.112<br>
<br>
Given a http prefix of <a href="http://my.elasticip:8080" target="_blank">http://my.elasticip:8080</a> which interface should it pick?<br>
<br>
As you can see here the prefixes are being used for both:<br>
<a href="https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L77" target="_blank">https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L77</a><br>
as well as some odd error conditions which I imagine are to match MS<br>
implementation but would need to verify that.<br>
<br>
If there was a separation between which interface to pick vs which<br>
http prefixes to use this would solve the problem and is essentially<br>
what I was talking about putting in as an overload. I know mono is as<br>
a whole a bit reluctant to add mono specific overloads (which is<br>
completely understandable). I just find kind any other reasonable way<br>
here of handling the windows/mono differences.<br>
<br>
<a href="https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpListener.cs#L269" target="_blank">https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpListener.cs#L269</a><br>
leads to<br>
<a href="https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L48" target="_blank">https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L48</a><br>
<br>
I could do this in a couple of ways (add state to HttpListener is an<br>
obvious one + an overload that only changes behaviour if its used).<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, May 20, 2015 at 12:18 AM, Miguel de Icaza <<a href="mailto:miguel@xamarin.com">miguel@xamarin.com</a>> wrote:<br>
> Shouldn't we bind on the interface based on the IP address?<br>
><br>
> Would that not solve the problem?<br>
><br>
> miguel<br>
><br>
> On Tue, May 19, 2015 at 4:00 PM, Greg Young <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>> wrote:<br>
>><br>
>> I was thinking a basic code api that allowed the specification of<br>
>> interface to bind to separately from which prefixes to accept to start<br>
>> with. The biggest issue here is that the ms api is basically using<br>
>> httpprefix to mean two very different things.<br>
>><br>
>> On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza <<a href="mailto:miguel@xamarin.com">miguel@xamarin.com</a>><br>
>> wrote:<br>
>> > Well, it might be best if you explain what you have in mind, before we<br>
>> > waste<br>
>> > time with a pull request.<br>
>> ><br>
>> > But either way works.<br>
>> ><br>
>> > On Tue, May 19, 2015 at 3:50 PM, Greg Young <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Miguel,<br>
>> >><br>
>> >> Would it be best to just take a stab at an alternative interface and<br>
>> >> send a PR for discussion?<br>
>> >><br>
>> >> Greg<br>
>> >><br>
>> >> On Sun, Apr 26, 2015 at 4:43 PM, Greg Young <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > This is the code handling the prefixes its here<br>
>> >> ><br>
>> >> ><br>
>> >> > <a href="https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43" target="_blank">https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43</a><br>
>> >> ><br>
>> >> > There is quite a bit of odd code around this in general. I understand<br>
>> >> > much of it is trying to reach compliance with MS but ...<br>
>> >> ><br>
>> >> > On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza <<a href="mailto:miguel@xamarin.com">miguel@xamarin.com</a>><br>
>> >> > wrote:<br>
>> >> >> Hello Greg,<br>
>> >> >><br>
>> >> >> Is that in HttpListener, or somewhere else?<br>
>> >> >><br>
>> >> >> Miguel<br>
>> >> >><br>
>> >> >> On Fri, Apr 24, 2015 at 12:41 PM, Greg Young<br>
>> >> >> <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >>><br>
>> >> >>> Here is some of the code in question:<br>
>> >> >>><br>
>> >> >>> IPAddress addr;<br>
>> >> >>> if (host == "*")<br>
>> >> >>>     addr = IPAddress.Any;<br>
>> >> >>> else if (IPAddress.TryParse(host, out addr) == false){<br>
>> >> >>>     try {<br>
>> >> >>>         IPHostEntry iphost = Dns.GetHostByName(host);<br>
>> >> >>>        if (iphost != null)<br>
>> >> >>>             addr = iphost.AddressList[0];<br>
>> >> >>>        else<br>
>> >> >>>             addr = IPAddress.Any;<br>
>> >> >>>    } catch {<br>
>> >> >>>         addr = IPAddress.Any;<br>
>> >> >>>    }<br>
>> >> >>> }<br>
>> >> >>><br>
>> >> >>> On Fri, Apr 24, 2015 at 7:29 PM, Greg Young<br>
>> >> >>> <<a href="mailto:gregoryyoung1@gmail.com">gregoryyoung1@gmail.com</a>><br>
>> >> >>> wrote:<br>
>> >> >>> > I have been going through a bunch of this code lately after<br>
>> >> >>> > seeing<br>
>> >> >>> > many ... interesting behaviours. I understand that much of the<br>
>> >> >>> > derp<br>
>> >> >>> > in<br>
>> >> >>> > this code is due to not having IIS and MS having an IIS centric<br>
>> >> >>> > API<br>
>> >> >>> > but wow. Some gems I have found...<br>
>> >> >>> ><br>
>> >> >>> > 1) synchronous dns calls being made...<br>
>> >> >>> > 2) I want to listen on <a href="http://192.168.0.1:1234" target="_blank">192.168.0.1:1234</a> but I want to support a<br>
>> >> >>> > host<br>
>> >> >>> > header of whateverdomain can't resolve whatever domain then bind<br>
>> >> >>> > listeners to all ips on machine.<br>
>> >> >>> > 3) Same as above but dns entry has multiple ips it resovles to<br>
>> >> >>> > [0]<br>
>> >> >>> > doesnt match see #2<br>
>> >> >>> > 4) Anything at all to do with elastic ips<br>
>> >> >>> > 5) Exceptions thrown to calling code with http status codes in<br>
>> >> >>> > them<br>
>> >> >>> > (I<br>
>> >> >>> > think this is ms legacy but is a pretty biog wtf)<br>
>> >> >>> > 6) failure parsing ip address says bind all interfaces on machine<br>
>> >> >>> > (huh?)<br>
>> >> >>> ><br>
>> >> >>> > Perhaps it makes sense to expose a "Microsoft Http Compatibility<br>
>> >> >>> > Layer" and then have a "Sane API if you want to use it"<br>
>> >> >>> ><br>
>> >> >>> > I dont mind putting some time in on these but is this even<br>
>> >> >>> > worthwhile<br>
>> >> >>> > or is the plan to just burn this code with fire and move to<br>
>> >> >>> > something<br>
>> >> >>> > sane in general?<br>
>> >> >>> ><br>
>> >> >>> > Cheers,<br>
>> >> >>> ><br>
>> >> >>> > Greg<br>
>> >> >>> > --<br>
>> >> >>> > Studying for the Turing test<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> --<br>
>> >> >>> Studying for the Turing test<br>
>> >> >>> _______________________________________________<br>
>> >> >>> Mono-devel-list mailing list<br>
>> >> >>> <a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
>> >> >>> <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Studying for the Turing test<br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Studying for the Turing test<br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Studying for the Turing test<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Studying for the Turing test<br>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</div></div></blockquote></div><br></div>