What you have shown is two threads having entirely independent GUIs with no
overlap, either in terms of
responsibility, or time - it would be extremely difficult for a user to click
on two elements sufficiently
quickly for any un-thread-safe code in the back end to execute simultaneously.
If you want to test whether
something is thread-safe, you need to run things on a busy loop basis, rather
than user input.
As a quick example, in iup_table.c you can find the iTableRemoveItem routine
which contains
/* re-order the remaining items */
for (i = itemIndex; i < entry->nextItemIndex-1; i++)
entry->items[i] = entry->items[i+1];
Were two threads to attempt that on the same entry simultaneously, utter mayhem
would ensue. Even worse
things might happen if two reallocs overlapped. I am not saying the above is
bad or wrong, just a cause
for concern in a multi-threaded sense, and there will be plenty of similar
examples in kernel32.dll and
gtk.so, etc.
What would be more interesting to me is a background thread managing to inform
the main gui thread that
it has completed some requested task, in a non-polling manner, especially on
gtk.
Pete
--------------------------------------------
On Sat, 18/2/17, John Spikowski <[email protected]> wrote:
I don't think IUP would take much to support threading.
> > > > I thought I would share my success with multi-threading IUP on
> > > > Windows
> > > > 10 with Script BASIC. I'm still early on with testing but so
> > > > far things look promising.
------------------------------------------------------------------------------
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
