On Fri, 1 Mar 2024 11:59:36 +0200
Pekka Paalanen wrote:
> ...
> The real problem here is though, how do you architect your app or
> toolkit so that it can stop and postpone what it is doing with Wayland
> when you detect that the socket is not draining fast enough? You might
> be calling into
On Thu, 29 Feb 2024 16:32:26 -0500
jleivent wrote:
> On Tue, 27 Feb 2024 11:01:18 +0200
> Pekka Paalanen wrote:
>
>
> > > But suppose I'm writing a client that has the possibility of
> > > sending a rapid stream of msgs to the compositor that might be,
> > > depending on what other clients
On Tue, 27 Feb 2024 11:01:18 +0200
Pekka Paalanen wrote:
> > But suppose I'm writing a client that has the possibility of
> > sending a rapid stream of msgs to the compositor that might be,
> > depending on what other clients are doing, too fast for the
> > compositor to handle, and I'd like to
On Mon, 26 Feb 2024 13:23:01 -0500
jleivent wrote:
> On Mon, 26 Feb 2024 15:12:23 +0200
> Pekka Paalanen wrote:
>
> ...
> > > What is the advantage to having the impacted clients grow their send
> > > buffers while waiting? They wait either way.
> >
> > They are not waiting if they are
On Mon, 26 Feb 2024 15:12:23 +0200
Pekka Paalanen wrote:
...
> > What is the advantage to having the impacted clients grow their send
> > buffers while waiting? They wait either way.
>
> They are not waiting if they are growing their send buffers.
I meant that they must wait for the UI to
On Sat, 24 Feb 2024 15:35:27 -0500
jleivent wrote:
> On Fri, 23 Feb 2024 12:12:38 +0200
> Pekka Paalanen wrote:
>
>
> > I would think it to be quite difficult for a compositor to dedicate a
> > whole thread for each client.
>
> But that means it is possible that the server cannot catch up
On Fri, 23 Feb 2024 12:12:38 +0200
Pekka Paalanen wrote:
> I would think it to be quite difficult for a compositor to dedicate a
> whole thread for each client.
But that means it is possible that the server cannot catch up for long
periods. And that just having a large number of otherwise
On Thu, 22 Feb 2024 10:26:00 -0500
jleivent wrote:
> Thanks for this response. I am considering adding unbounded buffering
> to my Wayland middleware project, and wanted to consider the flow
> control options first. Walking through the reasonsing here is very
> helpful. I didn't know that
Thanks for this response. I am considering adding unbounded buffering
to my Wayland middleware project, and wanted to consider the flow
control options first. Walking through the reasonsing here is very
helpful. I didn't know that there was a built-in expectation that
clients would do some of
On Wed, 21 Feb 2024 11:08:02 -0500
jleivent wrote:
> Not completely blocking makes sense for the compositor, but why not
> block the client?
Blocking in clients is indeed less of a problem, but:
- Clients do not usually have requests they *have to* send to the
compositor even if the
Not completely blocking makes sense for the compositor, but why not
block the client?
For the compositor, wouldn't a timeout in the sendmsg make sense?
On Wed, 21 Feb 2024 16:39:08 +0100
Olivier Fourdan wrote:
> Hi,
>
> On Wed, Feb 21, 2024 at 4:21 PM jleivent wrote:
>
> > I've been looking
Hi,
On Wed, Feb 21, 2024 at 4:21 PM jleivent wrote:
> I've been looking into some of the issues about allowing the socket's
> kernel buffer to run out of space, and was wondering why not simply
> remove MSG_DONTWAIT from the sendmsg call in wl_connection_flush? That
> should implement flow
I've been looking into some of the issues about allowing the socket's
kernel buffer to run out of space, and was wondering why not simply
remove MSG_DONTWAIT from the sendmsg call in wl_connection_flush? That
should implement flow control by having the sender thread wait until
the receiver has
13 matches
Mail list logo
