Howdy!
I was playing around with some wasm stuff using needletail. One of the main challenges is that most js_sys js objects are not Send.
Consider this example:
use needletail::parse_fastx_reader;
use wasm_bindgen::prelude::*;
use web_sys::FileReaderSync;
struct MyReader {
reader: FileReaderSync,
}
impl std::io::Read for MyReader {
fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> { Ok(0) }
}
#[wasm_bindgen]
pub fn some_func(reader: FileReaderSync) {
parse_fastx_reader(MyReader{ reader });
}
Running wasm-pack build --target web:
error[E0277]: `*mut u8` cannot be sent between threads safely
--> src/lib.rs:17:24
|
17 | parse_fastx_reader(MyReader{ reader });
| ------------------ ^^^^^^^^^^^^^^^^^^ `*mut u8` cannot be sent between threads safely
| |
| required by a bound introduced by this call
|
= help: within `MyReader`, the trait `Send` is not implemented for `*mut u8`, which is required by `MyReader: Send`
...
note: required by a bound in `parse_fastx_reader`
--> /home/j/third-party/needletail/src/parser/mod.rs:85:50
|
85 | pub fn parse_fastx_reader<'a, R: 'a + io::Read + Send>(
| ^^^^ required by this bound in `parse_fastx_reader`
However, it seems Send isn't strictly required. Dropping Send from the FastxReader here:
|
pub trait FastxReader: Send { |
And dropping it from both impls, the fastq and fasta reader, fixes compilation.
I'm sure I could wrap the reader in a mutex to make it Send but hammering a mutex (for lots of reads) introduces a lot of overhead.
From reading, it seems like Send is a nicety but even without the supertrait, if a caller passes in a Read that is also Send, the returned FastxReader would still be Send (but it's not always guaranteed to be). I'm not positive I have this correct.
So anyway, I wanted to see if you'd be open to removing Send from the fastx reader, and if you know of anything that could break in that case.
Thanks!
Howdy!
I was playing around with some wasm stuff using needletail. One of the main challenges is that most
js_sysjs objects are notSend.Consider this example:
Running
wasm-pack build --target web:However, it seems
Sendisn't strictly required. DroppingSendfrom theFastxReaderhere:needletail/src/parser/utils.rs
Line 119 in ba898bd
And dropping it from both impls, the fastq and fasta reader, fixes compilation.
I'm sure I could wrap the reader in a mutex to make it
Sendbut hammering a mutex (for lots of reads) introduces a lot of overhead.From reading, it seems like
Sendis a nicety but even without the supertrait, if a caller passes in aReadthat is alsoSend, the returnedFastxReaderwould still beSend(but it's not always guaranteed to be). I'm not positive I have this correct.So anyway, I wanted to see if you'd be open to removing
Sendfrom the fastx reader, and if you know of anything that could break in that case.Thanks!