All Projects → thk1 → send_wrapper

thk1 / send_wrapper

Licence: Apache-2.0, MIT licenses found Licenses found Apache-2.0 LICENSE-APACHE.txt MIT LICENSE-MIT.txt
No description or website provided.

Programming Languages

rust
11053 projects

Projects that are alternatives of or similar to send wrapper

Wepush
专注批量推送的小而美的工具,目前支持:模板消息-公众号、模板消息-小程序、微信客服消息、微信企业号/企业微信消息、阿里云短信、阿里大于模板短信 、腾讯云短信、云片网短信、E-Mail、HTTP请求、钉钉、华为云短信、百度云短信、又拍云短信、七牛云短信
Stars: ✭ 2,597 (+6558.97%)
Mutual labels:  send
TheWorldExchange
A purely client-side wallet and direct interface showcasing the full functionality of Ripple / blockchain.
Stars: ✭ 34 (-12.82%)
Mutual labels:  send
Simulink-Arduino-Serial
How to connect Arduino and Simulink
Stars: ✭ 54 (+38.46%)
Mutual labels:  send
muxnect
Send input to just about any interactive command-line tool through a local web server
Stars: ✭ 23 (-41.03%)
Mutual labels:  send
quartz-mailer
A library to get started in sending and receiving emails from and to your Crystal application
Stars: ✭ 23 (-41.03%)
Mutual labels:  send
interfax-ruby
Fax send and receive in Ruby with the InterFAX REST API
Stars: ✭ 16 (-58.97%)
Mutual labels:  send
Concurrent Map
a thread-safe concurrent map for go
Stars: ✭ 2,627 (+6635.9%)
Mutual labels:  thread-safety
Easyloggingpp
Single header C++ logging library. It is extremely powerful, extendable, light-weight, fast performing, thread and type safe and consists of many built-in features. It provides ability to write logs in your own customized format. It also provide support for logging your classes, third-party libraries, STL and third-party containers etc.
Stars: ✭ 3,032 (+7674.36%)
Mutual labels:  thread-safety
AtomicKit
Concurrency made simple in Swift.
Stars: ✭ 88 (+125.64%)
Mutual labels:  thread-safety
safe
C++11 header only RAII guards for mutexes and locks.
Stars: ✭ 119 (+205.13%)
Mutual labels:  thread-safety
lfqueue
Minimize lock-free queue ever!
Stars: ✭ 107 (+174.36%)
Mutual labels:  thread-safety
MemoryPool
simple memory pool / thread safe / minimized context switching / Memory managed in 4 levels / Requirements(Windows xp~ / Visualstudio 2015)
Stars: ✭ 14 (-64.1%)
Mutual labels:  thread-safety
concurrent-resource
A header-only C++ library that allows easily creating thread-safe, concurrency friendly resources.
Stars: ✭ 17 (-56.41%)
Mutual labels:  thread-safety
sled
A high performance lock free map type for go.
Stars: ✭ 18 (-53.85%)
Mutual labels:  thread-safety
lfqueue
lock-free FIFO queue by C native built it, easy built cross platform(no extra dependencies needed) , guarantee thread safety memory management ever!
Stars: ✭ 104 (+166.67%)
Mutual labels:  thread-safety

SendWrapper

This Rust crate implements a wrapper type called SendWrapper which allows you to move around non-Send types between threads, as long as you access the contained value only from within the original thread. You also have to make sure that the wrapper is dropped from within the original thread. If any of these constraints is violated, a panic occurs.

The idea for this crate was born in the context of a GTK+/gtk-rs-based application. GTK+ applications are strictly single-threaded. It is not allowed to call any GTK+ method from a thread different to the main thread. Consequently, all gtk-rs structs are non-Send.

Sometimes you still want to do some work in background. It is possible to enqueue GTK+ calls from there to be executed in the main thread using Glib. This way you can know, that the gtk-rs structs involved are only accessed in the main thread and will also be dropped there. This crate makes it possible for gtk-rs structs to leave the main thread.

Examples

use send_wrapper::SendWrapper;
use std::rc::Rc;
use std::thread;
use std::sync::mpsc::channel;

// This import is important. It allows you to unwrap the value using deref(),
// deref_mut() or Deref coercion.
use std::ops::{Deref, DerefMut};

// Rc is a non-Send type.
let value = Rc::new(42);

// We now wrap the value with `SendWrapper` (value is moved inside).
let wrapped_value = SendWrapper::new(value);

// A channel allows us to move the wrapped value between threads.
let (sender, receiver) = channel();

let t = thread::spawn(move || {

	// This would panic (because of dereferencing in wrong thread):
	// let value = wrapped_value.deref();

	// Move SendWrapper back to main thread, so it can be dropped from there.
	// If you leave this out the thread will panic because of dropping from wrong thread.
	sender.send(wrapped_value).unwrap();

});

let wrapped_value = receiver.recv().unwrap();

// Now you can use the value again.
let value = wrapped_value.deref();

// alternatives for dereferencing:
// let value = *wrapped_value;
// let value: &NonSendType = &wrapped_value;

// alternatives for mutable dereferencing (value and wrapped_value must be mutable too, then):
// let mut value = wrapped_value.deref_mut();
// let mut value = &mut *wrapped_value;
// let mut value: &mut NonSendType = &mut wrapped_value;

Wrapping Futures and Streams

To use SendWrapper on Futures or Streams, you should enable the Cargo feature futures first:

send_wrapper = { version = "0.5", features = ["futures"] }

Then, you can transparently wrap your Future or Stream:

use futures::{executor, future::{self, BoxFuture}};
use send_wrapper::SendWrapper;

// `Rc` is a `!Send` type,
let value = Rc::new(42);
// so this `Future` is `!Send` too as increments `Rc`'s inner counter.
let future = future::lazy(|_| value.clone());

// We now wrap the `future` with `SendWrapper` (value is moved inside),
let wrapped_future = SendWrapper::new(future);
// so now it's `Send` + `Sync` (`BoxFuture` trait object contains `Send` requirement).
let boxed_future: BoxFuture<_> = Box::pin(wrapped_future);

let t = thread::spawn(move || {
	// This would panic (because `future` is polled in wrong thread):
	// executor::block_on(boxed_future)
});

Changelog

See CHANGELOG.md

License

send_wrapper is distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE, and LICENSE-MIT for details.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].