Rustbox seems thread safe to me

[sebglazebrook]

I've been using rustbox across multiple threads and as long as I wrapped it in Arc::new(Mutex::new()) it's been fine.

[gchp]

@pythonesque can you comment on this? I can't remember what we talked about before surrounding this issue...thanks!

[gchp]

Just updating so you don't think I've forgotten this...I'm going to be testing this out in the morning. I've never tried using Rustbox over multiple threads, so it'll be interesting to see! Will come back once I've tested this out. Thanks for submitting!

[ticki]

What's the state of this?

[pythonesque]

It's not thread safe because it writes to a shared static buffer without synchronizing.

[sebglazebrook]

Sorry didn't see the update here.

Thanks for the reply @pythonesque.

It's the c termbox that's using the shared static buffer right?

If the rust library ensures thread safety then it's threadsafe right?

[phifty]

What's the state on this? It seems to me like this PR is an improvement for sure.

[jmacdonald]

Termbox is actually (partially) thread safe. This is the primary workflow I imagine for threaded Rustbox programs (and one I'm trying to leverage myself): one thread blocks on poll/peek_event, another thread renders using print.

To flag the Rustbox type as Sync and not introduce threading issues, we would need to handle synchronization internally: calls to mutating methods like print would need to acquire a lock, where as poll/peek_event would be available at any time.

[jmacdonald]

@gchp I think we can safely close this, as it's addressed by #81.

[gchp]

Thanks everyone for your comments and input, and apologies for the lack of movement. If you have any further issues/thoughts on this feel free to reach out.

And thanks @sebglazebrook for the original work.