fasthttp: multi threading fix reads in the socket in linux#26478

esquerbatua · 2026-01-31T18:50:44Z

fasthttp:

Allow to the user to select the family and max_request_buffer_size of the connection.
Fix read all of the data in the socket in linux.

veb:

Allows to run veb in multithreading with the flag: " -d new_veb"

spytheman · 2026-01-31T19:20:52Z

@esquerbatua try v fmt -w vlib/fasthttp to fix the CI

spytheman · 2026-01-31T19:21:35Z

also v git-fmt-hook install can make it so that each commit also runs vfmt automatically
(has to be run while your working folder is inside the v repo)

esquerbatua · 2026-01-31T20:10:02Z

Sorry I formatted the veb folder instead fasthttp, it's formatted now

enghitalo · 2026-01-31T20:23:30Z

I recommend not changing the logic behind closing the client connection for now.
Or you could do it in a separate PR, so you'd have to handle things like the HTTP version and request header to make it more appropriate. In fact, the perfect solution for me would be for veb to have the power to close the connection whenever it wants, but I haven't found a clever way to do this without creating a bit of a mess. Although, regardless of how it's done, it would still be much better than dealing with request interpretation within FastHTTP

esquerbatua · 2026-01-31T21:28:17Z

If I do not close the connection the client keeps waiting until timeout, tested.

enghitalo · 2026-02-01T02:54:21Z

If I do not close the connection the client keeps waiting until timeout, tested.

This is the default expected behavior for http1.1

enghitalo · 2026-02-01T02:59:03Z

@claude How connection should bahave in which http version? Show me the rfc reference.

esquerbatua · 2026-02-01T08:52:54Z

• HTTP/0.9 (very old, single-request): one TCP connection, one request, server returns raw response then closes. (No formal modern RFC; historical notes only.) • No persistent connections, no headers, no request/response framing.

• HTTP/1.0 (RFC 1945): by default the server closes the TCP connection after the response; clients and servers may use the Connection: keep-alive extension to request persistence, but it is optional and not reliably supported by all implementations. • RFC: RFC 1945 (HTTP/1.0).

• HTTP/1.1 (message framing, persistent by default): connections are persistent by default (multiple requests/responses can be sent sequentially on the same TCP connection). Pipelining (sending multiple requests without waiting for responses) is defined but problematic in practice; implementations more commonly use sequential requests or upgrade to multiplexing (HTTP/2). The Connection header and hop-by-hop semantics are defined here. • Key RFCs: • RFC 7230 (HTTP/1.1 message syntax and routing) — see section on connection management and persistent connections (RFC 7230 §6).
• RFC 7231 (semantics) and the rest of the RFC723x family for HTTP/1.1.

• HTTP/2 (binary framing, multiplexed streams over one TCP connection): a single TCP connection carries many independent, interleaved request/response streams concurrently (no head-of-line blocking at the HTTP message level, though TCP-level HOL remains). Uses HPACK for header compression and has explicit stream and connection lifecycle rules. • Key RFCs: • RFC 7540 (Hypertext Transfer Protocol Version 2) — see multiplexing, streams, connection flow control.
• RFC 7541 (HPACK — header compression).

• HTTP/3 (HTTP semantics over QUIC): moves from TCP to QUIC (UDP-based transport), giving multiplexing without TCP head-of-line blocking and integrated stream- and connection-level flow/congestion control; uses QPACK for header compression with HTTP/3-specific considerations. • Key RFCs: • RFC 9114 (HTTP/3)
• RFC 9000 (QUIC: the transport)
• RFC 9204 (QPACK — header compression for HTTP/3)

Pointers / exact references to read

esquerbatua · 2026-02-01T08:54:30Z

The point it's like if I use vweb or veb without flags, the service works as expected, if I use fast http, the connection keeps open

spytheman · 2026-02-01T11:04:30Z

Can there be a separate thread, that loops over all current opened connections, every say 10 seconds, and closes them, if there were no activity on them for say 1 minute?

enghitalo · 2026-02-01T11:45:48Z

@esquerbatua Can you share the code which you're facing issues?

esquerbatua · 2026-02-01T12:39:47Z

@esquerbatua Can you share the code which you're facing issues?

The simplest veb server should give timeout in all of the request. I didn't have time to test it changing the handing of the connection close.

module main

import veb { Result }

pub struct Context {
	veb.Context
}

struct App {
}

fn main() {
	mut app := App{}

	veb.run_at[App, Context](
		mut app,
		host: '0.0.0.0',
		port: 8080,
		family: .ip,
	) or { panic(err) }
}

@['/']
pub fn (app &App) index(mut ctx Context) Result {
	return ctx.ok('')
}

esquerbatua · 2026-02-01T12:48:46Z

Can there be a separate thread, that loops over all current opened connections, every say 10 seconds, and closes them, if there were no activity on them for say 1 minute?

Sorry if I'm wrong:

If we do that, always we are going to give extra time to all of the request, making veb or fasthttp so slow, make them useless with big load time and extra handle of the connection.
We should check if the connection have X request, process it in the same order that arrived. But that logic needs to be implemented.
Changing only the way that we close the connection we make fasthttp unusable.

enghitalo · 2026-02-01T12:57:46Z

Why not just close the connection at client side, as usual or handle Connection: close header at server veb side?

enghitalo · 2026-02-01T13:08:28Z

The point it's like if I use vweb or veb without flags, the service works as expected, if I use fast http, the connection keeps open

I'm sorry, but I'm still struggling to understand how the connection remaining active after sending the reply could be a problem

enghitalo · 2026-02-01T13:13:17Z

@esquerbatua

If I do not close the connection the client keeps waiting until timeout, tested.

The client doesn't have to wait for the connection timeout; it simply receives all the responses, check content-lenght and then closes automatically. Unless there's a problem with your client or the response you're sending.

esquerbatua · 2026-02-02T09:44:41Z

I reverted the changes in the clousure as they are, shouldn't modify the old behaviour @enghitalo

enghitalo · 2026-02-02T09:53:36Z

Thanks

spytheman

Is it all ready now?

esquerbatua · 2026-02-03T10:57:47Z

Is it all ready now?

yes

spytheman · 2026-02-03T18:01:17Z

 				// Read all available data from the socket
 				mut total_bytes_read := 0
-				mut all_data := []u8{cap: server.max_request_buffer_size}
+				mut readed_request_buffer := []u8{len: server.max_request_buffer_size, cap: server.max_request_buffer_size}


[]u8{len: server.max_request_buffer_size}

this it's not changed

spytheman

Thank you @esquerbatua 🙇🏻 .

Thank you @enghitalo .

esquerbatua added 2 commits January 31, 2026 19:29

WIP

eb2c216

Fix close client connection

f45de0d

spytheman requested review from enghitalo and medvednikov January 31, 2026 19:17

fmt

22ff572

Actualizar fasthttp_linux.v

6fd9152

Remove unused import

238601a

fix mac

96203fa

Revert clousure

b66f365

esquerbatua added 2 commits February 2, 2026 10:56

fix check

be0e5aa

fix mac

fc01b68

spytheman reviewed Feb 2, 2026

View reviewed changes

enghitalo approved these changes Feb 3, 2026

View reviewed changes

Comment thread vlib/fasthttp/fasthttp_linux.v Outdated

Comment thread vlib/fasthttp/fasthttp_linux.v Outdated

Comment thread vlib/fasthttp/fasthttp_linux.v Outdated

change all_data -> readed_request_buffer

62a69ca

spytheman reviewed Feb 3, 2026

View reviewed changes

spytheman approved these changes Feb 4, 2026

View reviewed changes

spytheman merged commit e20a432 into vlang:master Feb 4, 2026
78 checks passed

Uh oh!

Conversation

esquerbatua commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spytheman commented Jan 31, 2026

Uh oh!

spytheman commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

esquerbatua commented Jan 31, 2026

Uh oh!

enghitalo commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

esquerbatua commented Jan 31, 2026 • edited by enghitalo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

enghitalo commented Feb 1, 2026

Uh oh!

enghitalo commented Feb 1, 2026

Uh oh!

esquerbatua commented Feb 1, 2026

Uh oh!

esquerbatua commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spytheman commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

enghitalo commented Feb 1, 2026

Uh oh!

esquerbatua commented Feb 1, 2026 • edited by enghitalo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

esquerbatua commented Feb 1, 2026

Uh oh!

enghitalo commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

enghitalo commented Feb 1, 2026

Uh oh!

enghitalo commented Feb 1, 2026

Uh oh!

esquerbatua commented Feb 2, 2026

Uh oh!

enghitalo commented Feb 2, 2026

Uh oh!

spytheman left a comment

Choose a reason for hiding this comment

Uh oh!

esquerbatua commented Feb 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

spytheman Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

esquerbatua Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

spytheman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

esquerbatua commented Jan 31, 2026 •

edited

Loading

spytheman commented Jan 31, 2026 •

edited

Loading

enghitalo commented Jan 31, 2026 •

edited

Loading

esquerbatua commented Jan 31, 2026 •

edited by enghitalo

Loading

esquerbatua commented Feb 1, 2026 •

edited

Loading

spytheman commented Feb 1, 2026 •

edited

Loading

esquerbatua commented Feb 1, 2026 •

edited by enghitalo

Loading

enghitalo commented Feb 1, 2026 •

edited

Loading