server side callback

[Giulio Camuffo]

2013/3/12 Jason Ekstrand <jason at jlekstrand.net>:
> Guilio,
> The big problem here is that, unlike the server, events client-side
> are handled in multiple event loops.  Server-side, everything is
> handled in a single event loop and events (at least on a per-client
> basis) are handled in order (I think this is even in the spec).  On
> the client-side, where the event is handled depends on the object and
> the events may be handled in different threads.  For this reason, you
> can't just have a "sync" event because it may get handled in some
> other thread and actually be handled before an event that gets sent
> earlier.
>
> What might be possible, however, is to have a sync_next_event event
> (probably in wl_display).  This event would get detected in libwayland
> and "attached" to the subsequent event so that the server can get
> notified.  That said, there are a number of reasons why this may be a
> bad idea:
>
> 1. It breaks the asynchronous nature of libwayland.  Much of the
> wayland protocol is designed to avoid round-trips between client and
> server and this would add round trips.
>
> 2. Clients may not handle it correctly.  For instance, what if all the
> event handler did was to fire a signal inside the toolkit.  That
> signal might get executed right away or it may simply get queued for
> later execution on another thread.  If this happens, the server will
> get notified before the event actually does anything.
>
> 3. You have to deal with the the timeout case anyway.  The client may
> hang or crash in any event and the sync may never get sent.
>
> 4. This has the potential, if not used carefully, to lead to a lot of
> race conditions.  What happens if, inside of the synced event, the
> client does something and then calls wl_display_roundtrip?  While I
> think this could probably be handled correctly in most cases, it makes
> for a mess.

Ok, thanks for your insight.

>
> I'd love to offer some thoughts on the more general drag-and-drop
> problem if you want to give a more detailed description.
> Specifically, I read some of the conversation on IRC today, but I'm
> not sure I understand why the dropped event is needed.  That said, I
> may not be the best one to help you as I don't know the wayland D&D
> system that well, I'd mostly just be helping brainstorm.

When starting a drag, the source Qt app goes into a loop. It can still
redraw itself and get the events, but it is waiting for the dnd to
finish before going on with what it was doing. So i need a
notification, when the target has got the drop, which lets the source
client exit the loop and go on. If the source doesn't get this
notification it won't exit the loop and will be stuck. Besides, the
source needs it also to be able to free its wl_data_source.

>
> On Mon, Mar 11, 2013 at 4:53 PM, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>> Hi all,
>>
>> I've been struggling with a problem these last few days: I'm working
>> on QtWayland drag and drop support, and I noticed it requires some
>> protocol additions, of which this is a draft: https://pastee.org/hxq26
>> I want the" wl_data_source.dropped" event to be called after the
>> wl_data_device receives and returns from the the drop event. The
>> dropped event carries the action the target client chose, and i need
>> to be able to set the action (by calling
>> "wl_data_offer_accept_action") also from the "wl_data_device.drop"
>> event. Hence, i cannot simply post the "wl_data_source.dropped" event
>> just after the "wl_data_device.drop", because the
>> "wl_data_offer_accept_action" would be processed too late.
>>
>> I could require the client to issue a request "notify_drop", at the
>> end of the drop event listener, which would send the
>> "wl_data_source.dropped", but a client that fails to do so would be
>> troublesome: when a Qt client starts a drag it goes into a loop, which
>> is exited only when the data is dropped. If the target client didn't
>> send the "notify_drop" the source client would never exit from the
>> loop, making it stuck.
>> A timer could free it after some time, but that is not a good solution.
>>
>> What i need is a way to have a server-side callback when a certain
>> client-side event listener returns, all inside libwayland-client,
>> without the need for the client app to do anything. Is it possible?
>> I'm willing to implement it, but I don't know wayland's internals and
>> i'd need some pointing at.
>>
>> Thanks,
>> Giulio
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel