Re: thread support in Windows: problem
On 23:55 Thu 24 Jan , Tor Lillqvist wrote: Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. An interesting approach. Did you use some automated technique to generate these wrappers, or just manual work? It is not automated in the sense of having implemented it into gtk directly. However, I've made a library which of course sets up an architecture with wrappers and callback tables which in turn makes it easier to integrate those gtk widgets I personally had no need for yet. How well does it work and how general is it? I believe it works well, I've coded an app with several windows, a tree like selection and some 50 complex user interfaces created and deleted on the fly by selecting items from the tree. This app starts algorithms in the background as threads. They all may change widgets simultaneously (like log window entries, displaying images or simply change counters etc.). And it is portable on win32 and linux. Do you think it would be generally useful for other people, or is it just for your own specific need? Hm, from what I read in the mailing lists there seems to be some need to push gtk a bit from the thread-awareness towards the thread-safety. Are you interested in making your stuff available for others (and maintain it in the future...)? I'd like to spend some spare time to offer my experience, and the code, too, but I've got to talk to my boss if that is o.k. And there would be the need to separate this library from my win32/linux thread wrapper and keying (handle) system. Do you think it would help to first simply create a draft of the concept as a pdf or so for download ? Are there already plans to make gtk thread-safe (or reasons not to do so) ? As I mentioned it was necessary to wrap even the widgets itself to access their values immediatedly rather than bothering gtk and wait for the return of idle functions. So, the library IS something like a layer on top of gtk rather than something to be easily implemented into gtk. Would it make sense to you to continue this way ? Felix ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: thread support in Windows: problem
I am trying to run a simple(st) thread example in GTK with a windows-MinGW-Msys development environment Don't bother. You should not call GTK+ functions from multiple threads on Windows. It won't work. There are deep technical reasons for this, fixing it is in no way trivial. This has been mentioned several times over the years on this mailing list. Only call GTK+ functions from the thread (usually the main thread) that runs the GLib main loop, i.e. that calls gtk_main(). (Well, some limited (unknown) subset of GTK+ calls might work if called from other threads than the main thread. You have to experiment yourself.) Mingw unfortunately doesnt provide thread headers and libraries[pthread.h is unavailable]. Mingw provides the API for the native Win32 thread API and the Microsoft C library thread functions in its header just fine. That is what it should do. Mingw is not about POSIX emulation. The p in pthread stands for POSIX. That said, there does exist a good implementation of the pthread API to Windows. (It wraps the native Win32 thread API.) Google for pthreads-win32. You probably found it already? (That doesn't change the situation, though. Using GTK+ from multiple threads won't work on Windows no matter what API you use to create the threads.) But anyway, why don't you use the GThread API, which might be more natural in a GTK+ program. (But I repeat once more, using GTK+ from multiple threads won't work on Windows no matter what API you use to create the threads.) I have copied the headers[pthread.h, sched.h and semaphore.h] into the mingw include folder, and I have copied the libraries for threads all into mingw lib folder. Without central package management (like on Linux), it is a bad idea to mix stuff from different origins in the same tree. Don't copy headers and libraries around so that you end up with a multitude of copies here and there. It will only confuse you later when you perhaps decide to upgrade to a fresher mingw and blow away the old mingw tree, forgetting that you had added other stuff there. Keep only what the mingw project distributes in the mingw tree, and things downloaded from other places in some systematic way in specific trees. Use -I and -L flags as appropriate when building, and set PATH when running. I even use a -Lpath during compilation of my thread application. Well, d'oh. Using -L flags are a very basic thing. Program compiles but the executable fails to link to the downloaded libraries [which I have supplied in the -L and l options to gcc]. Do you know the difference between import libraries and DLLs? When using DLLs, the libraries you specify when linking with -l are (typically) import libraries. These aren't used at run time. The -L switch has no effect on where the executable looks for DLLs at run time. Nor has any other switch you can give at link time. Unlike most Unix systems, on Windows one can't store in an executable's header any run-time look-up path for shared libraries. Message tells me dll not found. You need to read up on how Windows locates DLLs required by a starting program. Hint: PATH. I thought it might have something to do with registering the DLL with the OS, and so I used regsvr32 to get DLL registered, but registration somehow failed[I am not a geek and so I was not able to figure out why it failed]. Registering DLLs is related to COM and/or OLE, and has nothing to do with normal DLLs. DISCLAIMER Please stop attaching multiple copies of the ridiculous disclaimer to your messages. It doesn't improve your credibility. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: thread support in Windows: problem
On 11:37 Thu 24 Jan , Tor Lillqvist wrote: I am trying to run a simple(st) thread example in GTK with a windows-MinGW-Msys development environment Don't bother. You should not call GTK+ functions from multiple threads on Windows. It won't work. There are deep technical reasons for this, fixing it is in no way trivial. This has been mentioned several times over the years on this mailing list. I've tried to make gtk work with threads on win32 and linux for a long time now and I am finally proud to say, it is possible -- but, as Tor said, not trivial. Just some notes on how to make the first steps towards that: Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. Additionally (!) you need to lock gtk/gdk access by the gds_threads_enter/leave functions -- since idle functions are not auto-locked by gtk (like signals are). When you get deeper into this topic you'll probably stuble accross the problem that idle functions are kind of a one way: you can launch an idle function e.g. to rename a label but what if you want to read out the current value of an entry widget? You want the result right when you ask, however the idle function comes back at some later point of time. The solution I took was not to wait for that idle function but create wrappers for the gtk widgets which keep the data and can be queried without asking gtk; this of course needs you to update the data whenever the user changes the real gtk widget. Good luck, it IS possible. Felix ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: thread support in Windows: problem
[EMAIL PROTECTED] wrote: Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. Additionally (!) you need to lock gtk/gdk access by the gds_threads_enter/leave functions -- since idle functions are not auto-locked by gtk (like signals are). Well, if you set it up so all gtk/gdk functions end up being called by the main thread by using g_idle_add(), then there's no reason to call gdk_threads_init() and thus no need to use gdk_threads_enter/leave(). A bit simpler that way. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: thread support in Windows: problem
On Thu, 2008-01-24 at 21:26 +0100, [EMAIL PROTECTED] wrote: I've tried to make gtk work with threads on win32 and linux for a long time now and I am finally proud to say, it is possible -- but, as Tor said, not trivial. [snip] Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. Additionally (!) you need to lock gtk/gdk access by the gds_threads_enter/leave functions -- since idle functions are not auto-locked by gtk (like signals are). It's pointless calling gdk_threads_enter()/leave() in windows because it won't work. It's also unnecessary in your use because the callback for g_idle_add() executes in the GTK+ main loop and not in the calling thread - which is fine, and works well. So your approach is correct, except as regards the need to call gdk_threads_enter()/leave(). Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: thread support in Windows: problem
Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. An interesting approach. Did you use some automated technique to generate these wrappers, or just manual work? How well does it work and how general is it? Do you think it would be generally useful for other people, or is it just for your own specific need? Are you interested in making your stuff available for others (and maintain it in the future...)? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
