Hello Jeremiah, Even if connection "data" is stored in Gnoga protected object, that is only a pointer as you guess right. So it remains up to the main program to care about the concurrent access of the data in a multitask context as Gnoga is.
HTH, Pascal. http://blady.pagesperso-orange.fr > Le 8 avr. 2017 à 03:05, Jeremiah Breeden <jeremiah.bree...@gmail.com> a écrit > : > > I was trying to figure out how Connection_Data is handled with respect to > Task safety. In particular, if I have two Action_Event handlers and in each > of the I do something like: > > My_App : My_App_Access := My_App_Access(Object.Connection_Data); > > And then proceed to use it in both action event handlers, how does Gnoga > prevent the two handlers from having concurrency issues with what My_App > points to? > > As far as I can tell, Connection_Data is stored simply as an access variable > in the connection_manager. Granted, the function to get the access variable > is from a protected object, but we copy that pointer into a local unprotected > access variable. What prevents both handlers from trying to set the same > parameter at the same time (not talking about the parameters pushed via the > websocket but those stored locally in the object...maps, Strings, counts, > etc.)? > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot_______________________________________________ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
