On 4/17/18, Antonio Scuri <[email protected]> wrote:
> Hi,
>
> I got your message. But It will take a couple of days to figure this out.
>
> Best,
> Scuri
>
No problem. I know there is a lot to read over. While I think the
actual implementation and impact on IUP is very small, since this
focuses on concerns not usually discussed with IUP, I felt I needed to
describe everything in detail to get everybody on the same page.
Here is a little more information I would like to add.
First, I made a copy/paste mistake in Idea 2 concerning the
IupSetAttribute(). That should have been deleted since in that case,
that would just work automatically since we have an Ihandle*.
Second, here are a few more edge-case details to fill out a more
complete specification of the feature proposal:
===
- IupPostMessage() should also be safe to call on the main UI thread.
- It should not cause a deadlock.
Discussion: Effectively, all the implementations are adding the
message to the platform’s native event loop queue. That message will
get processed in due time as the queue is processed on the main UI
thread. If IupPostMessage() gets posted from the main UI thread, this
is fine, because the message is still simply added to the queue, and
will be processed sometime in the future when the event queue is
processed.
It is useful to demand we not deadlock because there may be situations where:
a) The user may not know for certain if they are on a background
thread (for cross-platform projects, maybe on some platforms they are,
and others are not)
b) This feature can also be useful for those who want to implement
single-threaded async-like patterns.
=====
Further discussion about how to do other platform implementations not
mentioned (e.g. Motif, Haiku, etc):
Note: I am not familiar with these other backends so my comments are
very general, assuming a bad case scenario where nothing is available.
It could be that all the platforms we care about have an easy solution
like the others.
- Presumably all GUI platforms all have some concept of an event
queue. So any implementation should be looking for a way to add the
message to its event queue which presumably gets processed on the main
UI thread.
- In the absence of such a mechanism, we have a few fallback
positions we can decide between:
a) Do nothing and mark as unsupported in the documentation.
b) Implement our own private event queue and using a polling
mechanism (either from pumping the platform’s native event loop, or
using something like IupTimer to poll periodically), then process the
event.
c) Invoke the callback immediately when IupPostMessage() is
called.
Discussion of (a):
Pros: Easy to implement (don’t have to do anything)
Cons: Can break cross-platform code that was expecting a callback to
happen. And this thing can be hard to debug if they don’t understand
that this will be a no-op on the platform they are testing. (Perhaps
an assert can be thrown if called to alert the developer that this is
unsupported.)
Discussion of (b):
Pros: Writing our own event queue and polling for it manually should
be possible in all real world cases I can imagine. The fact that we
are expected to have IupTimer() means we have a way to poll
periodically if the native event loop is not accessible to us for some
strange reason.
Cons: Requires more implementation on our part, including writing a
thread-safe queue.
Discussion of (c):
In the absence of any other mechanisms, we can just immediately turn
around and invoke the callback
Pros: This solves the missing callback problem of (a).
This is also very easy to implement.
Cons: This may be technically wrong since we are potentially invoking
on a background thread and may confuse the user. (But presumably, if
they are using a backend that we can’t support, it is an old platform
and they probably weren’t using threads to begin with and the call is
actually on the main thread, which is safe.))
- Addition note: I noticed that Motif seems to have a global locking
API that locks the entire GUI so it is safe to call from any thread.
So one possibility is in cases like this, we call lock, then run the
callback, and then unlock. Effectively, this will achieve the original
goal of allowing the user to call GUI code safely from a background
thread.
Thanks,
Eric
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/iup-users
