2024-01-01 14:58:21 -05:00
|
|
|
// Copyright 2018-2024 the Deno authors. All rights reserved. MIT license.
|
2021-04-13 07:25:21 -04:00
|
|
|
|
2021-08-16 08:29:54 -04:00
|
|
|
use crate::ops::TestingFeaturesEnabled;
|
2020-12-06 22:30:40 -05:00
|
|
|
use crate::web_worker::run_web_worker;
|
2021-06-22 10:30:16 -04:00
|
|
|
use crate::web_worker::SendableWebWorkerHandle;
|
2020-11-26 09:17:45 -05:00
|
|
|
use crate::web_worker::WebWorker;
|
|
|
|
use crate::web_worker::WebWorkerHandle;
|
2021-08-16 08:29:54 -04:00
|
|
|
use crate::web_worker::WebWorkerType;
|
2021-06-22 10:30:16 -04:00
|
|
|
use crate::web_worker::WorkerControlEvent;
|
2021-05-11 15:09:09 -04:00
|
|
|
use crate::web_worker::WorkerId;
|
2024-03-15 20:59:18 -04:00
|
|
|
use crate::web_worker::WorkerMetadata;
|
2022-04-26 19:06:10 -04:00
|
|
|
use crate::worker::FormatJsErrorFn;
|
2023-09-14 17:05:18 -04:00
|
|
|
use deno_core::op2;
|
2021-01-06 15:31:16 -05:00
|
|
|
use deno_core::serde::Deserialize;
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
use deno_core::CancelFuture;
|
|
|
|
use deno_core::CancelHandle;
|
2020-04-23 05:51:07 -04:00
|
|
|
use deno_core::ModuleSpecifier;
|
2020-09-10 09:57:45 -04:00
|
|
|
use deno_core::OpState;
|
2024-06-06 23:37:53 -04:00
|
|
|
use deno_permissions::ChildPermissionsArg;
|
|
|
|
use deno_permissions::PermissionsContainer;
|
2024-03-15 20:59:18 -04:00
|
|
|
use deno_web::deserialize_js_transferables;
|
2021-06-22 10:30:16 -04:00
|
|
|
use deno_web::JsMessageData;
|
2024-10-22 04:41:08 -04:00
|
|
|
use deno_web::MessagePortError;
|
2021-03-26 12:34:25 -04:00
|
|
|
use log::debug;
|
2020-09-10 09:57:45 -04:00
|
|
|
use std::cell::RefCell;
|
2020-09-19 19:17:35 -04:00
|
|
|
use std::collections::HashMap;
|
2020-08-18 12:30:13 -04:00
|
|
|
use std::rc::Rc;
|
2020-12-11 12:49:26 -05:00
|
|
|
use std::sync::Arc;
|
2019-10-11 14:41:54 -04:00
|
|
|
|
2023-11-01 18:15:08 -04:00
|
|
|
pub const UNSTABLE_FEATURE_NAME: &str = "worker-options";
|
2023-10-12 11:55:50 -04:00
|
|
|
|
2020-12-11 12:49:26 -05:00
|
|
|
pub struct CreateWebWorkerArgs {
|
|
|
|
pub name: String,
|
2021-05-11 15:09:09 -04:00
|
|
|
pub worker_id: WorkerId,
|
2023-01-07 11:25:34 -05:00
|
|
|
pub parent_permissions: PermissionsContainer,
|
|
|
|
pub permissions: PermissionsContainer,
|
2020-12-11 12:49:26 -05:00
|
|
|
pub main_module: ModuleSpecifier,
|
2021-08-16 08:29:54 -04:00
|
|
|
pub worker_type: WebWorkerType,
|
2024-03-13 13:22:25 -04:00
|
|
|
pub close_on_idle: bool,
|
2024-03-15 20:59:18 -04:00
|
|
|
pub maybe_worker_metadata: Option<WorkerMetadata>,
|
2020-12-11 12:49:26 -05:00
|
|
|
}
|
|
|
|
|
2021-06-22 10:30:16 -04:00
|
|
|
pub type CreateWebWorkerCb = dyn Fn(CreateWebWorkerArgs) -> (WebWorker, SendableWebWorkerHandle)
|
|
|
|
+ Sync
|
|
|
|
+ Send;
|
2020-12-11 12:49:26 -05:00
|
|
|
|
|
|
|
/// A holder for callback that is used to create a new
|
|
|
|
/// WebWorker. It's a struct instead of a type alias
|
|
|
|
/// because `GothamState` used in `OpState` overrides
|
2022-02-11 07:41:56 -05:00
|
|
|
/// value if type aliases have the same underlying type
|
2020-12-11 12:49:26 -05:00
|
|
|
#[derive(Clone)]
|
2022-08-16 21:00:35 -04:00
|
|
|
struct CreateWebWorkerCbHolder(Arc<CreateWebWorkerCb>);
|
2020-12-11 12:49:26 -05:00
|
|
|
|
2022-04-26 19:06:10 -04:00
|
|
|
#[derive(Clone)]
|
2022-08-16 21:00:35 -04:00
|
|
|
struct FormatJsErrorFnHolder(Option<Arc<FormatJsErrorFn>>);
|
|
|
|
|
2021-01-06 15:31:16 -05:00
|
|
|
pub struct WorkerThread {
|
|
|
|
worker_handle: WebWorkerHandle,
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
cancel_handle: Rc<CancelHandle>,
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
|
|
|
|
// A WorkerThread that hasn't been explicitly terminated can only be removed
|
|
|
|
// from the WorkersTable once close messages have been received for both the
|
|
|
|
// control and message channels. See `close_channel`.
|
|
|
|
ctrl_closed: bool,
|
|
|
|
message_closed: bool,
|
2021-01-06 15:31:16 -05:00
|
|
|
}
|
|
|
|
|
2021-09-22 12:02:15 -04:00
|
|
|
impl WorkerThread {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
fn terminate(self) {
|
|
|
|
// Cancel recv ops when terminating the worker, so they don't show up as
|
|
|
|
// pending ops.
|
|
|
|
self.cancel_handle.cancel();
|
2021-09-22 12:02:15 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Drop for WorkerThread {
|
|
|
|
fn drop(&mut self) {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
self.worker_handle.clone().terminate();
|
2021-09-22 12:02:15 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-11 15:09:09 -04:00
|
|
|
pub type WorkersTable = HashMap<WorkerId, WorkerThread>;
|
2021-01-06 15:31:16 -05:00
|
|
|
|
2023-03-17 14:22:15 -04:00
|
|
|
deno_core::extension!(
|
|
|
|
deno_worker_host,
|
|
|
|
ops = [
|
|
|
|
op_create_worker,
|
|
|
|
op_host_terminate_worker,
|
|
|
|
op_host_post_message,
|
|
|
|
op_host_recv_ctrl,
|
|
|
|
op_host_recv_message,
|
|
|
|
],
|
2023-03-17 18:15:27 -04:00
|
|
|
options = {
|
2023-03-17 14:22:15 -04:00
|
|
|
create_web_worker_cb: Arc<CreateWebWorkerCb>,
|
|
|
|
format_js_error_fn: Option<Arc<FormatJsErrorFn>>,
|
|
|
|
},
|
2023-03-17 18:15:27 -04:00
|
|
|
state = |state, options| {
|
2023-03-17 14:22:15 -04:00
|
|
|
state.put::<WorkersTable>(WorkersTable::default());
|
|
|
|
|
|
|
|
let create_web_worker_cb_holder =
|
2023-03-17 18:15:27 -04:00
|
|
|
CreateWebWorkerCbHolder(options.create_web_worker_cb);
|
2023-03-17 14:22:15 -04:00
|
|
|
state.put::<CreateWebWorkerCbHolder>(create_web_worker_cb_holder);
|
|
|
|
let format_js_error_fn_holder =
|
2023-03-17 18:15:27 -04:00
|
|
|
FormatJsErrorFnHolder(options.format_js_error_fn);
|
2023-03-17 14:22:15 -04:00
|
|
|
state.put::<FormatJsErrorFnHolder>(format_js_error_fn_holder);
|
2023-03-18 18:30:04 -04:00
|
|
|
},
|
2023-03-17 14:22:15 -04:00
|
|
|
);
|
2020-02-11 04:04:59 -05:00
|
|
|
|
2019-08-26 08:50:21 -04:00
|
|
|
#[derive(Deserialize)]
|
|
|
|
#[serde(rename_all = "camelCase")]
|
2021-03-18 14:42:01 -04:00
|
|
|
pub struct CreateWorkerArgs {
|
2019-08-26 08:50:21 -04:00
|
|
|
has_source_code: bool,
|
2021-01-06 15:31:16 -05:00
|
|
|
name: Option<String>,
|
2021-10-13 13:04:44 -04:00
|
|
|
permissions: Option<ChildPermissionsArg>,
|
2019-08-26 08:50:21 -04:00
|
|
|
source_code: String,
|
2021-01-06 15:31:16 -05:00
|
|
|
specifier: String,
|
2021-08-16 08:29:54 -04:00
|
|
|
worker_type: WebWorkerType,
|
2024-03-13 13:22:25 -04:00
|
|
|
close_on_idle: bool,
|
2019-08-14 11:03:02 -04:00
|
|
|
}
|
|
|
|
|
2024-10-22 04:41:08 -04:00
|
|
|
#[derive(Debug, thiserror::Error)]
|
|
|
|
pub enum CreateWorkerError {
|
|
|
|
#[error("Classic workers are not supported.")]
|
|
|
|
ClassicWorkers,
|
|
|
|
#[error(transparent)]
|
2024-11-04 12:17:21 -05:00
|
|
|
Permission(deno_permissions::ChildPermissionError),
|
2024-10-22 04:41:08 -04:00
|
|
|
#[error(transparent)]
|
|
|
|
ModuleResolution(#[from] deno_core::ModuleResolutionError),
|
|
|
|
#[error(transparent)]
|
|
|
|
MessagePort(#[from] MessagePortError),
|
|
|
|
#[error("{0}")]
|
|
|
|
Io(#[from] std::io::Error),
|
|
|
|
}
|
|
|
|
|
2019-08-14 11:03:02 -04:00
|
|
|
/// Create worker as the host
|
2024-11-20 16:24:04 -05:00
|
|
|
#[op2(stack_trace)]
|
2023-09-14 17:05:18 -04:00
|
|
|
#[serde]
|
2019-10-11 14:41:54 -04:00
|
|
|
fn op_create_worker(
|
2020-09-10 09:57:45 -04:00
|
|
|
state: &mut OpState,
|
2023-09-14 17:05:18 -04:00
|
|
|
#[serde] args: CreateWorkerArgs,
|
2024-03-11 18:18:03 -04:00
|
|
|
#[serde] maybe_worker_metadata: Option<JsMessageData>,
|
2024-10-22 04:41:08 -04:00
|
|
|
) -> Result<WorkerId, CreateWorkerError> {
|
2020-02-03 18:08:44 -05:00
|
|
|
let specifier = args.specifier.clone();
|
2020-04-16 17:40:29 -04:00
|
|
|
let maybe_source_code = if args.has_source_code {
|
|
|
|
Some(args.source_code.clone())
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
};
|
2020-02-03 18:08:44 -05:00
|
|
|
let args_name = args.name;
|
2021-08-16 08:29:54 -04:00
|
|
|
let worker_type = args.worker_type;
|
|
|
|
if let WebWorkerType::Classic = worker_type {
|
|
|
|
if let TestingFeaturesEnabled(false) = state.borrow() {
|
2024-10-22 04:41:08 -04:00
|
|
|
return Err(CreateWorkerError::ClassicWorkers);
|
2021-08-16 08:29:54 -04:00
|
|
|
}
|
|
|
|
}
|
2021-10-13 13:04:44 -04:00
|
|
|
|
|
|
|
if args.permissions.is_some() {
|
2023-10-12 11:55:50 -04:00
|
|
|
super::check_unstable(
|
|
|
|
state,
|
|
|
|
UNSTABLE_FEATURE_NAME,
|
|
|
|
"Worker.deno.permissions",
|
|
|
|
);
|
2021-10-13 13:04:44 -04:00
|
|
|
}
|
2023-01-07 11:25:34 -05:00
|
|
|
let parent_permissions = state.borrow_mut::<PermissionsContainer>();
|
2021-10-13 13:04:44 -04:00
|
|
|
let worker_permissions = if let Some(child_permissions_arg) = args.permissions
|
|
|
|
{
|
2024-10-22 04:41:08 -04:00
|
|
|
parent_permissions
|
|
|
|
.create_child_permissions(child_permissions_arg)
|
|
|
|
.map_err(CreateWorkerError::Permission)?
|
2021-01-06 15:31:16 -05:00
|
|
|
} else {
|
|
|
|
parent_permissions.clone()
|
|
|
|
};
|
2021-10-13 13:04:44 -04:00
|
|
|
let parent_permissions = parent_permissions.clone();
|
2023-09-25 21:01:56 -04:00
|
|
|
let create_web_worker_cb = state.borrow::<CreateWebWorkerCbHolder>().clone();
|
|
|
|
let format_js_error_fn = state.borrow::<FormatJsErrorFnHolder>().clone();
|
2024-03-13 15:52:53 -04:00
|
|
|
let worker_id = WorkerId::new();
|
2020-02-08 14:34:31 -05:00
|
|
|
|
2021-02-17 13:47:18 -05:00
|
|
|
let module_specifier = deno_core::resolve_url(&specifier)?;
|
2022-11-17 20:59:10 -05:00
|
|
|
let worker_name = args_name.unwrap_or_default();
|
2020-12-06 22:30:40 -05:00
|
|
|
|
2024-10-22 04:41:08 -04:00
|
|
|
let (handle_sender, handle_receiver) =
|
|
|
|
std::sync::mpsc::sync_channel::<SendableWebWorkerHandle>(1);
|
2020-12-06 22:30:40 -05:00
|
|
|
|
|
|
|
// Setup new thread
|
2023-01-27 10:43:16 -05:00
|
|
|
let thread_builder = std::thread::Builder::new().name(format!("{worker_id}"));
|
2024-03-15 20:59:18 -04:00
|
|
|
let maybe_worker_metadata = if let Some(data) = maybe_worker_metadata {
|
|
|
|
let transferables =
|
|
|
|
deserialize_js_transferables(state, data.transferables)?;
|
|
|
|
Some(WorkerMetadata {
|
|
|
|
buffer: data.data,
|
|
|
|
transferables,
|
|
|
|
})
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
};
|
2020-12-06 22:30:40 -05:00
|
|
|
// Spawn it
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
thread_builder.spawn(move || {
|
2020-12-06 22:30:40 -05:00
|
|
|
// Any error inside this block is terminal:
|
|
|
|
// - JS worker is useless - meaning it throws an exception and can't do anything else,
|
|
|
|
// all action done upon it should be noops
|
|
|
|
// - newly spawned thread exits
|
2020-12-11 12:49:26 -05:00
|
|
|
|
2021-06-22 10:30:16 -04:00
|
|
|
let (worker, external_handle) =
|
2022-02-11 07:41:56 -05:00
|
|
|
(create_web_worker_cb.0)(CreateWebWorkerArgs {
|
2021-06-22 10:30:16 -04:00
|
|
|
name: worker_name,
|
|
|
|
worker_id,
|
|
|
|
parent_permissions,
|
|
|
|
permissions: worker_permissions,
|
|
|
|
main_module: module_specifier.clone(),
|
2021-08-16 08:29:54 -04:00
|
|
|
worker_type,
|
2024-03-13 13:22:25 -04:00
|
|
|
close_on_idle: args.close_on_idle,
|
2024-03-11 18:18:03 -04:00
|
|
|
maybe_worker_metadata,
|
2021-06-22 10:30:16 -04:00
|
|
|
});
|
2020-12-06 22:30:40 -05:00
|
|
|
|
2021-05-11 15:09:09 -04:00
|
|
|
// Send thread safe handle from newly created worker to host thread
|
2024-10-22 04:41:08 -04:00
|
|
|
handle_sender.send(external_handle).unwrap();
|
2020-12-06 22:30:40 -05:00
|
|
|
drop(handle_sender);
|
|
|
|
|
|
|
|
// At this point the only method of communication with host
|
|
|
|
// is using `worker.internal_channels`.
|
|
|
|
//
|
|
|
|
// Host can already push messages and interact with worker.
|
2022-02-11 07:41:56 -05:00
|
|
|
run_web_worker(
|
|
|
|
worker,
|
|
|
|
module_specifier,
|
|
|
|
maybe_source_code,
|
2022-04-26 19:06:10 -04:00
|
|
|
format_js_error_fn.0,
|
2022-02-11 07:41:56 -05:00
|
|
|
)
|
2020-12-06 22:30:40 -05:00
|
|
|
})?;
|
|
|
|
|
2021-05-11 15:09:09 -04:00
|
|
|
// Receive WebWorkerHandle from newly created worker
|
2024-10-22 04:41:08 -04:00
|
|
|
let worker_handle = handle_receiver.recv().unwrap();
|
2020-12-06 22:30:40 -05:00
|
|
|
|
|
|
|
let worker_thread = WorkerThread {
|
2021-06-22 10:30:16 -04:00
|
|
|
worker_handle: worker_handle.into(),
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
cancel_handle: CancelHandle::new_rc(),
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
ctrl_closed: false,
|
|
|
|
message_closed: false,
|
2020-12-06 22:30:40 -05:00
|
|
|
};
|
2020-01-17 18:43:53 -05:00
|
|
|
|
2020-02-11 04:04:59 -05:00
|
|
|
// At this point all interactions with worker happen using thread
|
2020-12-06 22:30:40 -05:00
|
|
|
// safe handler returned from previous function calls
|
2020-09-19 19:17:35 -04:00
|
|
|
state
|
|
|
|
.borrow_mut::<WorkersTable>()
|
2020-12-06 22:30:40 -05:00
|
|
|
.insert(worker_id, worker_thread);
|
2019-08-26 08:50:21 -04:00
|
|
|
|
2021-04-05 12:40:24 -04:00
|
|
|
Ok(worker_id)
|
2019-08-14 11:03:02 -04:00
|
|
|
}
|
|
|
|
|
2023-09-14 17:05:18 -04:00
|
|
|
#[op2]
|
|
|
|
fn op_host_terminate_worker(state: &mut OpState, #[serde] id: WorkerId) {
|
2021-07-16 18:51:06 -04:00
|
|
|
if let Some(worker_thread) = state.borrow_mut::<WorkersTable>().remove(&id) {
|
2021-09-22 12:02:15 -04:00
|
|
|
worker_thread.terminate();
|
2021-07-16 18:51:06 -04:00
|
|
|
} else {
|
|
|
|
debug!("tried to terminate non-existent worker {}", id);
|
|
|
|
}
|
2020-01-17 18:43:53 -05:00
|
|
|
}
|
|
|
|
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
enum WorkerChannel {
|
|
|
|
Ctrl,
|
|
|
|
Messages,
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Close a worker's channel. If this results in both of a worker's channels
|
|
|
|
/// being closed, the worker will be removed from the workers table.
|
|
|
|
fn close_channel(
|
|
|
|
state: Rc<RefCell<OpState>>,
|
|
|
|
id: WorkerId,
|
|
|
|
channel: WorkerChannel,
|
|
|
|
) {
|
|
|
|
use std::collections::hash_map::Entry;
|
|
|
|
|
2020-12-06 22:30:40 -05:00
|
|
|
let mut s = state.borrow_mut();
|
|
|
|
let workers = s.borrow_mut::<WorkersTable>();
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
|
|
|
|
// `Worker.terminate()` might have been called already, meaning that we won't
|
|
|
|
// find the worker in the table - in that case ignore.
|
|
|
|
if let Entry::Occupied(mut entry) = workers.entry(id) {
|
|
|
|
let terminate = {
|
|
|
|
let worker_thread = entry.get_mut();
|
|
|
|
match channel {
|
|
|
|
WorkerChannel::Ctrl => {
|
|
|
|
worker_thread.ctrl_closed = true;
|
|
|
|
worker_thread.message_closed
|
|
|
|
}
|
|
|
|
WorkerChannel::Messages => {
|
|
|
|
worker_thread.message_closed = true;
|
|
|
|
worker_thread.ctrl_closed
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
if terminate {
|
2021-09-22 12:02:15 -04:00
|
|
|
entry.remove().terminate();
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
}
|
2020-12-06 22:30:40 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-22 10:30:16 -04:00
|
|
|
/// Get control event from guest worker as host
|
2023-09-14 17:05:18 -04:00
|
|
|
#[op2(async)]
|
|
|
|
#[serde]
|
2021-06-22 10:30:16 -04:00
|
|
|
async fn op_host_recv_ctrl(
|
2020-09-10 09:57:45 -04:00
|
|
|
state: Rc<RefCell<OpState>>,
|
2023-09-14 17:05:18 -04:00
|
|
|
#[serde] id: WorkerId,
|
2024-10-22 04:41:08 -04:00
|
|
|
) -> WorkerControlEvent {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
let (worker_handle, cancel_handle) = {
|
2021-06-22 10:30:16 -04:00
|
|
|
let state = state.borrow();
|
|
|
|
let workers_table = state.borrow::<WorkersTable>();
|
2020-09-10 09:57:45 -04:00
|
|
|
let maybe_handle = workers_table.get(&id);
|
|
|
|
if let Some(handle) = maybe_handle {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
(handle.worker_handle.clone(), handle.cancel_handle.clone())
|
2020-09-10 09:57:45 -04:00
|
|
|
} else {
|
|
|
|
// If handle was not found it means worker has already shutdown
|
2024-10-22 04:41:08 -04:00
|
|
|
return WorkerControlEvent::Close;
|
2020-09-10 09:57:45 -04:00
|
|
|
}
|
2020-08-28 11:08:24 -04:00
|
|
|
};
|
|
|
|
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
let maybe_event = worker_handle
|
|
|
|
.get_control_event()
|
|
|
|
.or_cancel(cancel_handle)
|
|
|
|
.await;
|
|
|
|
match maybe_event {
|
2024-10-22 04:41:08 -04:00
|
|
|
Ok(Some(event)) => {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
// Terminal error means that worker should be removed from worker table.
|
|
|
|
if let WorkerControlEvent::TerminalError(_) = &event {
|
|
|
|
close_channel(state, id, WorkerChannel::Ctrl);
|
|
|
|
}
|
2024-10-22 04:41:08 -04:00
|
|
|
event
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
}
|
2024-10-22 04:41:08 -04:00
|
|
|
Ok(None) => {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
// If there was no event from worker it means it has already been closed.
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
close_channel(state, id, WorkerChannel::Ctrl);
|
2024-10-22 04:41:08 -04:00
|
|
|
WorkerControlEvent::Close
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
}
|
|
|
|
Err(_) => {
|
|
|
|
// The worker was terminated.
|
2024-10-22 04:41:08 -04:00
|
|
|
WorkerControlEvent::Close
|
2020-08-28 11:08:24 -04:00
|
|
|
}
|
2020-12-06 22:30:40 -05:00
|
|
|
}
|
2021-06-22 10:30:16 -04:00
|
|
|
}
|
|
|
|
|
2023-09-14 17:05:18 -04:00
|
|
|
#[op2(async)]
|
|
|
|
#[serde]
|
2021-06-22 10:30:16 -04:00
|
|
|
async fn op_host_recv_message(
|
|
|
|
state: Rc<RefCell<OpState>>,
|
2023-09-14 17:05:18 -04:00
|
|
|
#[serde] id: WorkerId,
|
2024-10-22 04:41:08 -04:00
|
|
|
) -> Result<Option<JsMessageData>, MessagePortError> {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
let (worker_handle, cancel_handle) = {
|
2021-06-22 10:30:16 -04:00
|
|
|
let s = state.borrow();
|
|
|
|
let workers_table = s.borrow::<WorkersTable>();
|
|
|
|
let maybe_handle = workers_table.get(&id);
|
|
|
|
if let Some(handle) = maybe_handle {
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
(handle.worker_handle.clone(), handle.cancel_handle.clone())
|
2021-06-22 10:30:16 -04:00
|
|
|
} else {
|
|
|
|
// If handle was not found it means worker has already shutdown
|
|
|
|
return Ok(None);
|
|
|
|
}
|
|
|
|
};
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
let ret = worker_handle
|
|
|
|
.port
|
|
|
|
.recv(state.clone())
|
|
|
|
.or_cancel(cancel_handle)
|
|
|
|
.await;
|
|
|
|
match ret {
|
|
|
|
Ok(Ok(ret)) => {
|
|
|
|
if ret.is_none() {
|
|
|
|
close_channel(state, id, WorkerChannel::Messages);
|
|
|
|
}
|
|
|
|
Ok(ret)
|
|
|
|
}
|
2024-10-22 04:41:08 -04:00
|
|
|
Ok(Err(err)) => Err(err),
|
fix(workers): Make `worker.terminate()` not block the current thread (#13941)
Calling `worker.terminate()` used to kill the worker's isolate and
then block until the worker's thread finished. This blocks the calling
thread if the worker's event loop was blocked in a sync op (as with
`Deno.sleepSync`), which wasn't realized at the time, but since the
worker's isolate was killed at that moment, it would not block the
calling thread if the worker was in a JS endless loop.
However, in #12831, in order to work around a V8 bug, worker
termination was changed to first set a signal to let the worker event
loop know that termination has been requested, and only kill the
isolate if the event loop has not finished after 2 seconds. However,
this change kept the blocking, which meant that JS endless loops in
the worker now blocked the parent for 2 seconds.
As it turns out, after #12831 it is fine to signal termination and
even kill the worker's isolate without waiting for the thread to
finish, so this change does that. However, that might leave the async
ops that receive messages and control data from the worker pending
after `worker.terminate()`, which leads to odd results from the op
sanitizer. Therefore, we set up a `CancelHandler` to cancel those ops
when the worker is terminated.
2022-04-27 12:22:47 -04:00
|
|
|
Err(_) => {
|
|
|
|
// The worker was terminated.
|
|
|
|
Ok(None)
|
|
|
|
}
|
Don't drop messages from workers that have already been closed (#11913)
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
2021-09-06 05:05:02 -04:00
|
|
|
}
|
2019-08-26 08:50:21 -04:00
|
|
|
}
|
|
|
|
|
2019-08-14 11:03:02 -04:00
|
|
|
/// Post message to guest worker as host
|
2023-09-14 17:05:18 -04:00
|
|
|
#[op2]
|
2019-10-11 14:41:54 -04:00
|
|
|
fn op_host_post_message(
|
2020-09-10 09:57:45 -04:00
|
|
|
state: &mut OpState,
|
2023-09-14 17:05:18 -04:00
|
|
|
#[serde] id: WorkerId,
|
|
|
|
#[serde] data: JsMessageData,
|
2024-10-22 04:41:08 -04:00
|
|
|
) -> Result<(), MessagePortError> {
|
2021-07-16 18:51:06 -04:00
|
|
|
if let Some(worker_thread) = state.borrow::<WorkersTable>().get(&id) {
|
|
|
|
debug!("post message to worker {}", id);
|
|
|
|
let worker_handle = worker_thread.worker_handle.clone();
|
|
|
|
worker_handle.port.send(state, data)?;
|
|
|
|
} else {
|
|
|
|
debug!("tried to post message to non-existent worker {}", id);
|
|
|
|
}
|
2021-04-05 12:40:24 -04:00
|
|
|
Ok(())
|
2019-08-14 11:03:02 -04:00
|
|
|
}
|