The OpenCL code calls must also be made in its own thread. It may even have to be the main thread (I'll have to check). Ever since the new thread code landed in SVN the OpenCL code crashes and doesn't work. Still I'm not sure if it's because of that or some other reason. But it's been a bit hard to track down the specific cause. I'm currently behind a slow network connection so checking it version by version until finding the culprit changeset is kinda hard right now.
Regards, On Wed, Jul 4, 2018 at 6:21 PM, Daniel Roßberg <danielmrossb...@gmail.com> wrote: > 2018-07-04 7:26 GMT+02:00 Christopher Sean Morrison via brlcad-devel > <brlcad-devel@lists.sourceforge.net>: >> >> >> On Jun 27, 2018, at 12:36 PM, Daniel Roßberg <danielmrossb...@gmail.com> >> wrote: >> >> Is the Tk-mged supposed to work with multiple threads? It looks like if a >> simple call to bu_log() in a subthread can crash it. >> >> >> It is supposed to work, but that’s been historically tricky code to get >> right and keep working because of how libbu manages a set of global locks. >> Currently, nearly everything goes through BU_SEM_SYSCALL which means you >> can’t recursively call bu functions from bu functions safely without hitting >> a deadlock, race, or other issue. This is particularly problematic for >> bu_log() and it’s hook functions (which very often are written to call bu >> functions, but that’s nfg) and bu_malloc() and friends. >> >> What’s needed is breaking up BU_SEM_SYSCALL into different semaphores for >> each of the respective bu groupings that need to coordinate some access. > > > I'm afraid there is an additional issue with calling Tk functions: In > general, Tk functions have to be called all from the same thread because > they use thread specific memory. See e.g. this thread: > https://sourceforge.net/p/tktoolkit/bugs/1359/ > > And, this was the reason why we see crashes with check_overlaps: Tk_FreeGC() > calls TkGetDisplay() which looks at thread specific data, can't find > anything there, and returned NULL which Tk_FreeGC() tries to dereferenciate. > According to the above mentioned discussion, there are specific Tcl/Tk APIs > for queuing events from one thread into another, which would be necessary to > use in a multi thread Tk-mged. > > > Regards, > Daniel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > -- Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
