Multicore version of Lwt_preemptive #1
Conversation
It is used internally to implement system_limit, which already returns int option. There is no behaviour change.
IOV_MAX is optional in POSIX [1], so it is not defined if the OS does not specify an actual limit. Hence, make lwt_unix_iov_max simply return None, as it is handled already by the callers. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
Handle an optional IOV_MAX
| if worker.reuse then worker_loop worker | ||
| match C.recv worker.task_chan with | ||
| | Task (id, task) -> | ||
| task (); |
There was a problem hiding this comment.
Isn't the task type here a result type? There should be a pattern match here right?
There was a problem hiding this comment.
task here is the function that's supposed to be executed. The task doesn't return the result, but it stores it elsewhere in the detach function.
| task_cell = CELL.make (); | ||
| thread = Thread.self (); | ||
| reuse = true; | ||
| task_chan = C.make_bounded 0; |
There was a problem hiding this comment.
I'm a little confused since I'm not aware of the internal workings but initializing the channel bound as zero, isn't that equivalent to a synchronous channel? -> https://github.com/ocaml-multicore/domainslib/blob/2ac25c7a207e199281f702560e20f3e7c4069088/lib/chan.ml#L27
There was a problem hiding this comment.
It is indeed a synchronous channel. Since we are going to send only one task at a time to this channel, shouldn't really matter for performance. If we do see some impact in the performance, we can increase the buffer size.
|
Some performance numbers for a benchmark that uses Multicore version of Number of clients: 10
|
No description provided.