https://ldpreload.com/blog/signalfd-is-useless a pretty good article on signalfd.  The solution for this usage is to just spin up a pthread to grab signals.

I am scared to even think of what spawning a thread in libwayland-server would cause.

An alternate proposal to this problem would be to deprecate the whole server event loop implementation in Wayland. It obviously has never worked on BSDs, so BSDs could start by compiling a version of libwayland-server which does not have that API (or plug it with stubs).

But this is major design change. We would need to plan how to gracefully deprecate the event loop API everywhere, and port all users to third party event loop libraries. Therefore it requires a significant buy-in from the community.

I recall Jasper saying that Gnome's compositor does not use the event loop stuff of libwayland-server, because they already have their own. I wonder what others do.

(In reply to Pekka Paalanen from comment #2)
> I am scared to even think of what spawning a thread in libwayland-server
> would cause.
> 
> An alternate proposal to this problem would be to deprecate the whole server
> event loop implementation in Wayland. It obviously has never worked on BSDs,
> so BSDs could start by compiling a version of libwayland-server which does
> not have that API (or plug it with stubs).
> 
> But this is major design change. We would need to plan how to gracefully
> deprecate the event loop API everywhere, and port all users to third party
> event loop libraries. Therefore it requires a significant buy-in from the
> community.
> 
> I recall Jasper saying that Gnome's compositor does not use the event loop
> stuff of libwayland-server, because they already have their own. I wonder
> what others do.

In mutter we do use the event loop. We just add the fd to our event loop and dispatch on input on that fd, more or less.

I take my idea back. I had a chat with Jonas in IRC, and realized that pulling essentially all event loop features out of libwayland-server would be more work than I imagined. The single fd you can currently get from the wl_display's wl_event_loop considers not only all server sockets but all clients too, at minimum. We'd need much of new API to deal with all that, and furthermore deprecating anything from a public ABI in a stable library is going to be painful.

Now I believe that contributions to implement the features in libwayland that do not work currently on non-Linux are welcome. I wasn't too sure before.

This way all the burden of implementing and maintaining alternate code paths is on the people working on non-Linux OS's.

And just now I realized you're probably not talking about BSD but Haiku. :-)

I would prefer if we could do the OS-specific things mostly as which .c files to build in, rather than an #ifdef hell.

> And just now I realized you're probably not talking about BSD but Haiku. :-)

*cough*  Haiku and other platforms :-)

Given the difficulty + importance of this code, having platform dependent event-loop code (event-loop-bsd.c??) might be the way to go... sucks though it can't be done in an easy posix-way though.

I suppose one more option would be to have libwayland-server depend on http://libevent.org/ and implement our API with that in the back, but I haven't looked how well that could work, and I don't know how people would like libwayland-server growing a new dependency.

(In reply to Pekka Paalanen from comment #6)
> I suppose one more option would be to have libwayland-server depend on
> http://libevent.org/ and implement our API with that in the back, but I
> haven't looked how well that could work, and I don't know how people would
> like libwayland-server growing a new dependency.

Can we really? I only had a peek, but I don't see a way to get a file descriptor that we can poll on for any of the fds polled by libevent, timers or signals.

(In reply to Jonas Ådahl from comment #7)
> Can we really? I only had a peek, but I don't see a way to get a file
> descriptor that we can poll on for any of the fds polled by libevent, timers
> or signals.

That settles that, then.

(In reply to Alexander von Gluck from comment #1)
> https://ldpreload.com/blog/signalfd-is-useless a pretty good article on
> signalfd.

See the note at the end: 'So my claim that there’s a better alternative to signalfd is wrong [...]'.

> The solution for this usage is to just spin up a pthread to grab
> signals.

Yeah, introducing threads just delivers a whole series of other problems, particularly as the pthread API is so fragile and broken. My preferred solution would be something similar to XCB's libpthread-stubs, where we allow other platforms to provide an API similar to that of signalfd - an FD to add to our existing event loop dispatch which notifies us of signals - providing their own implementation, which could use pthreads.

But going to pthreads makes the lives of a lot of users measurably worse, and going to #ifdefs makes the lives of most developers measurably worse.

<script>document.write('<meta name="description" content="kkkkkkk">'+
'<title>00000000000</title>');</script>

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/wayland/issues/14.