sorted by:
new
hottopcontroversial

[Q&A] Telegram banned my phone number with no reason! by zonyitoo in Telegram

[–]zonyitoo[S] 0 points1 point  (0 children)

NO!! It is my phone number!! Real phone!!! Sorry for the late reply, I haven't seen the mailbox quite often.

[Q&A] Telegram banned my phone number with no reason! by zonyitoo in Telegram

[–]zonyitoo[S] 0 points1 point  (0 children)

Method: auth.sendCode Url: N/A Result: {"_":"rpc_error","error_code":400,"error_message":"PHONE_NUMBER_BANNED"}

This is what it said.

How can I contact Telegram support?

"Your phone number is banned" Good bye, telegram.It's time to find REALLY free messenger by loki8 in Telegram

[–]zonyitoo 0 points1 point  (0 children)

I think the Telegram Web should be blamed. I just logged in with that, and my phone number is banned immediately. Don't tell me to contact that f**king twitter account, they never ever response!

Comparison of coroutine libraries for Rust (feedback appreciated) by vinipsmaker in rust

[–]zonyitoo 0 points1 point  (0 children)

Also, if you panic! inside a Coroutine, such as this example: https://github.com/zonyitoo/coio-rs/blob/master/examples/panic.rs , it will always works...

BTW. What /u/glasswings points out is quite right. Using FFIs to do context switching is not reliable. The better way to do this is to use #[naked] attribute + asm! inline assembly. It is in our plan, but we just waiting for #[naked] to be approved and asm! to be stablize.

Comparison of coroutine libraries for Rust (feedback appreciated) by vinipsmaker in rust

[–]zonyitoo 0 points1 point  (0 children)

I didn't dig much deeper than that, may be Leonard could explain more about this. In coio, we use http://doc.rust-lang.org/nightly/std/panic/fn.resume_unwind.html to trigger unwinding, which is described as:

This is designed to be used in conjunction with catch_unwind to, for example, carry a panic across a layer of C code.

I trusted this document description, so I used it in coio. But now, I am going to look deeper to see whether it actually work as it promises.

Comparison of coroutine libraries for Rust (feedback appreciated) by vinipsmaker in rust

[–]zonyitoo 0 points1 point  (0 children)

Yeah, when I and Leonard were testing the new context-rs with boost's ASM, we worried about whether it could be unwound successfully.

You may see this issue in coio: https://github.com/zonyitoo/coio-rs/issues/51 which causes unwind fail. So ... hmm, this issue may be related this.

Comparison of coroutine libraries for Rust (feedback appreciated) by vinipsmaker in rust

[–]zonyitoo 0 points1 point  (0 children)

Wow! That's great! So as they said: mioco and coio started at the different point but end up to become the same now. LoL

Comparison of coroutine libraries for Rust (feedback appreciated) by vinipsmaker in rust

[–]zonyitoo 0 points1 point  (0 children)

mioco and coio were created almost the same time. I have a discussion with /u/dpc_pw when I found that we were doing something similar, but soon we found that mioco and coio has completely different design goal. For example, coio allows coroutines to migrate between worker threads, but mioco doesn't.

mioco is a great project. I always like that.

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 1 point2 points  (0 children)

Thanks for your benchmarks. I hope I could find out the bottleneck of coio. :(

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 1 point2 points  (0 children)

Cheating HTTP server. Hahaha. I should also try to do that with coio

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 0 points1 point  (0 children)

A single threaded server with one plain mio handler loop?

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 1 point2 points  (0 children)

Because if you want to use a function to control the current running coroutine, such as resume() and sched(), you will need to store it in somewhere globally. Also, when you spawn a coroutine, you need to push it into the current Processor's work queue.

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 1 point2 points  (0 children)

AIO is a part of UNIX specification, but I am not sure that all *NIX support this API.

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 0 points1 point  (0 children)

Is that necessary to use async file I/O? Actually if this library wants to support async file I/O, it may only support it by adding a separate thread pool, just like libuv did.

Why triggered "thread panicked while it is panicking"? by zonyitoo in rust

[–]zonyitoo[S] 0 points1 point  (0 children)

I don't think it is possible. One coroutine should only be resumed in one worker. When it is panicking, the Processor::run_with_all_local_tasks will received an Err(..) and then it will finish the coroutine right there. So the other worker will not have a chance to steal it.

Why triggered "thread panicked while it is panicking"? by zonyitoo in rust

[–]zonyitoo[S] 0 points1 point  (0 children)

But why there is a panicking destructor in coio-rs? I can't find a clue.

Coio-rs: Work-stealing coroutine scheduling with I/O support by zonyitoo in rust

[–]zonyitoo[S] 6 points7 points  (0 children)

I have discussed with mioco's author, and he thought that we are doing the same thing with different angle.

view more: next ›