Skip to content

Add read_upto and rename read to read_exactly#2

Merged
talex5 merged 1 commit intoocaml-multicore:mainfrom
talex5:read-upto
Mar 11, 2021
Merged

Add read_upto and rename read to read_exactly#2
talex5 merged 1 commit intoocaml-multicore:mainfrom
talex5:read-upto

Conversation

@talex5
Copy link
Copy Markdown
Collaborator

@talex5 talex5 commented Mar 11, 2021

read would keep waiting until it had filled the buffer. When reading e.g. an HTTP request from a network connection, you don't know how long it will be and should just process whatever data arrives.

`read` would keep waiting until it had filled the buffer. When reading
e.g. an HTTP request from a network connection, you don't know how long
it will be and should just process whatever data arrives.
@talex5 talex5 merged commit 334f2c1 into ocaml-multicore:main Mar 11, 2021
@talex5 talex5 deleted the read-upto branch March 11, 2021 15:37
@avsm
Copy link
Copy Markdown
Contributor

avsm commented Mar 11, 2021

One thing I think we should consider is to expose separate higher level functions for operations over files and network sockets. They're just fundamentally different: you want seeking/offsets in files and buffering, and short read/writes in network operations with precise control over flushing.

haesbaert added a commit to haesbaert/eio that referenced this pull request Dec 1, 2022
When I removed the `e` and I violated GC #rule 5. Basically a small block must
be fully initialized before we trigger the next allocation, TIL.
talex5 added a commit to talex5/eio that referenced this pull request Jul 27, 2023
The `execve` action allocated the arrays in the forked child process.
However, in a multi-threaded program we might have forked while another
thread had the malloc lock. In that case, the child would wait forever
because it inherited the locked mutex but not the thread that would
unlock it. e.g.

    #0  futex_wait (private=0, expected=2, futex_word=0xffff9509cb10 <main_arena>) at ../sysdeps/nptl/futex-internal.h:146
    ocaml-multicore#1  __GI___lll_lock_wait_private (futex=futex@entry=0xffff9509cb10 <main_arena>) at ./nptl/lowlevellock.c:34
    ocaml-multicore#2  0x0000ffff94f8e780 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at ./malloc/malloc.c:3650
    ocaml-multicore#3  0x0000aaaac67cfa68 in make_string_array (errors=errors@entry=37, v_array=281472912006504) at fork_action.c:47
    ocaml-multicore#4  0x0000aaaac67cfaf4 in action_execve (errors=37, v_config=281472912003024) at fork_action.c:61
    ocaml-multicore#5  0x0000aaaac67cf93c in eio_unix_run_fork_actions (errors=errors@entry=37, v_actions=281472912002960) at fork_action.c:19
talex5 added a commit to talex5/eio that referenced this pull request Jul 28, 2023
The `execve` action allocated the arrays in the forked child process.
However, in a multi-threaded program we might have forked while another
thread had the malloc lock. In that case, the child would wait forever
because it inherited the locked mutex but not the thread that would
unlock it. e.g.

    #0  futex_wait (private=0, expected=2, futex_word=0xffff9509cb10 <main_arena>) at ../sysdeps/nptl/futex-internal.h:146
    ocaml-multicore#1  __GI___lll_lock_wait_private (futex=futex@entry=0xffff9509cb10 <main_arena>) at ./nptl/lowlevellock.c:34
    ocaml-multicore#2  0x0000ffff94f8e780 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at ./malloc/malloc.c:3650
    ocaml-multicore#3  0x0000aaaac67cfa68 in make_string_array (errors=errors@entry=37, v_array=281472912006504) at fork_action.c:47
    ocaml-multicore#4  0x0000aaaac67cfaf4 in action_execve (errors=37, v_config=281472912003024) at fork_action.c:61
    ocaml-multicore#5  0x0000aaaac67cf93c in eio_unix_run_fork_actions (errors=errors@entry=37, v_actions=281472912002960) at fork_action.c:19
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