RejectedSoftware Forums

Sign up

Why must websocket handlers take a scope WebSocket?

I'm using vibe's websocket handler. It requires a function with the signature void function(scope WebSocket).

I need to receive data from the socket and also wait for events that require me to send data to the socket. This is relatively inconvenient right now. The solution I currently have is to use a thread-safe queue and non-blocking operations and manually yielding -- since there's no way to yield-wait for two things at once.

It would be more straightforward and have less performance overhead to be able to share the socket between several fibers. I can do this today, but that involves casting away scope, which isn't safe.

Is there a better way of doing this?

Re: Why must websocket handlers take a scope WebSocket?

Am 30.12.2016 um 18:07 schrieb dhasenan:

I'm using vibe's websocket handler. It requires a function with the signature void function(scope WebSocket).

I need to receive data from the socket and also wait for events that require me to send data to the socket. This is relatively inconvenient right now. The solution I currently have is to use a thread-safe queue and non-blocking operations and manually yielding -- since there's no way to yield-wait for two things at once.

It would be more straightforward and have less performance overhead to be able to share the socket between several fibers. I can do this today, but that involves casting away scope, which isn't safe.

Is there a better way of doing this?

One thing I frequently found to be potentially quite useful would be
some kind of ScopedTask that is guaranteed to finish before the parent
scope is exited. Values could then be passed to this task as scope
with the necessary casts happening inside of the implementation in a
@trusted way. I'll create a ticket for this.

But because DMD currently doesn't really enforce scope, this actually
currently also works with normal tasks:
https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d#incremental-updates