Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XHR #166

Merged
merged 46 commits into from
Feb 15, 2024
Merged

XHR #166

merged 46 commits into from
Feb 15, 2024

Conversation

krichprollsch
Copy link
Member

@krichprollsch krichprollsch commented Jan 26, 2024

@krichprollsch krichprollsch self-assigned this Jan 26, 2024
@krichprollsch
Copy link
Member Author

POC for async http client: https://github.com/krichprollsch/zig-async-http

@krichprollsch krichprollsch changed the title Xhr XHR Jan 29, 2024
@krichprollsch krichprollsch marked this pull request as ready for review January 31, 2024 14:16
done: bool = false,
err: ?anyerror = null,

pub fn deinit(self: *AsyncRequest) void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit stange to have a deinit without an init

return self.impl.yield(self);
}

fn onerr(self: *AsyncRequest, err: anyerror) void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

onErr?


pub fn create(self: *AsyncClient, uri: std.Uri) !AsyncRequest {
return .{
.impl = YieldImpl.init(self.cli.loop),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because Yield is a struct with data, we have to store it's instance on the Request. If it was only a container of functions we wouldn't need that.

self.cli.deinit();
}

pub fn create(self: *AsyncClient, uri: std.Uri) !AsyncRequest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's not enough self explanatory. createRequest?

self.err = err;
}

pub fn onYield(self: *AsyncRequest, err: ?anyerror) void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

onYield is blocking right?

var reqs: [10]AsyncClient.AsyncRequest = undefined;
for (0..reqs.len) |i| {
reqs[i] = try client.create(try std.Uri.parse(url));
reqs[i].fetch();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm having difficulties to understand how this is non-blocking.

Let's say we have 3 requests (A, B, C).
For me the execution process is the following:

  • Create and launch fetch A
  • Create and launch fetch B
  • Create and launch fetch C
  • Process A
  • Process B
  • Process C

OK process is done after all requests are created and launched, but still as soon as the onYield callback is called each requests is process on a blocking way.
There is no concurrency here, no?


pub const Loop = @import("jsruntime").Loop;

const TCPClient = @import("tcp.zig").Client;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this const is not used in this file.

@krichprollsch krichprollsch merged commit 10777a7 into main Feb 15, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants