[haiku-development] Re: Plan for NetServices Kit (v2)

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Wed, 1 Sep 2021 07:32:31 +0100

Hi!

On Tue, Aug 31, 2021 at 11:00 AM Andrew Lindesay <apl@xxxxxxxxxxxxxx> wrote:

I am hoping for some insights and discussion.

Hello Niels;

Thank you for working on this proposal.

One thing that is problematic in HaikuDepot is cancelling HTTP requests
because the as-built `BNetworkRequest::_ResolveHostName` uses the blocking
`getaddrinfo` and so the cancel doesn't work if it blocks on the name
resolution on the caller thread.  I have read that libcurl provides a
mechanism for the user to provide a plug-able name lookup mechanism in so
there is an option to run `getaddrinfo` in another thread, but that's still
not awesome.  I'm not sure if there's an obvious solution here, but this
problem would be worth considering in the design; can we transparently
cancel the URL requests if they are still doing DNS lookups somehow?


From the perspective of you as a user, you set up the properties of the
request, and then you hand it over to the BHttpSession instance to execute
it. Resolving the DNS is done within the threads of the BHttpSession, so
this will not block you as the application, and it does not prevent you to
cancel a request even when it is in the DNS resolution stage. There are two
supported ways to cancel a request. One way is to just drop the result out
of scope. The BHttpSession will 'notice' that no one is waiting for the
result, and clean up the request. If you need to make sure that the request
is cancelled, you can also actively cancel it and wait for it to be fully
closed.

I will review the possibilities of doing non-blocking DNS lookups to make
sure they will not block other requests from being executed.


I would also like to voice some concern about the newer C++ features
coming in for things like errors, collections and references.  I don't
explicitly object, but I think this needs to be done carefully and
cohesively in a strategy for all public interfaces on the platform.


I agree, and I think that might be an exercise we would want to do
separately first. I am going to share my thoughts as a PR we can
review/discuss on Gerrit, so we can do line by line comments and/or flame
wars.


The "classic" code of HakuDepot returning `status_t` and the
exception-throwing code of the PackageKit are rather odd together and I
sometimes wonder if it would have been better one way or the other but not
both.  The idea of introducing a third way seems like it will really cause
some confusion.  The easiest thing would be to stick with the old way
returning `status_t` because it will cause less change and less work.  If
it is going to be changed however, it need to be coupled with an
all-of-platform strategy around this.


 Also agreed. Having said that, unless the final decision is to stay with
the legacy error handling without exceptions and using status_t and invalid
objects, it seems likely that we will end up in a situation where there
would be legacy error handling (in the older kits) and modern error
handling (in newer kits).

Regards,

N>

Other related posts: