On Sat, Apr 8, 2017 at 4:40 AM, Jeffrey R. Carter wrote:
> On 04/08/2017 03:05 AM, Jeremiah Breeden wrote:
> > 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?
>
> This is only an issue if the events are both from the same connection. If
> the
> events are from different connections, then the pointers are different and
> you
> don't have to worry about it. Multi-connect programs would be difficult to
> implement if this wasn't the case.
>
> Since events are really user interactions with the Gnoga GUI, and
> computers are
> much faster than people, this is not a concern for most programs.
>
> However, Gnoga seems to respond to a user interaction by creating a task
> which
> calls the appropriate event handler. If the processing of one event can
> take
> long enough that the user can generate another event, then this can become
> an
> issue. I encountered this when porting Mine_Detector to Gnoga. The
> responses to
> some events at some points in the game took seconds, and it was easy to
> generate
> a 2nd event which would interfere with the 1st and result in an invalid
> game
> state. My solution was for all event handlers to call a protected entry,
> serializing the event handling. I used an entry with a barrier of True
> rather
> than a protected procedure so the calls would be queued and handled in the
> correct order.
>
This is kind of the same type of case for me. I have some events that may
take a longer time, so the events could overlapp. I wanted to check
because Gnoga is advertised as being built with concurrency in mind, but I
had noticed that the basic mechanism for getting a connection's data
structure might be dangerous in that respect. I wanted to make sure I
wasn't missing something. (note that I am not saying the advert is wrong,
just my interpretation of it). In either case, it wasn't something that
was intuitive to me at first glance. Since each event happens in its own
task, I had hoped that the connection data object that the event object has
access to would have been task safe. Now that I know, I can make sure to
be careful when I have use cases that matter. Thanks for clearing it up
for me!
> On Sat, Apr 8, 2017 at 4:40 AM, Jeffrey R. Carter wrote:
> My solution is really for the singleton case, though. In the multi-connect
> version, all the event handlers are going through the same entry, so an
> event
> has to wait for all other players' events to complete before being
> processed.
> The multi-connect version should really have a protected object per
> connection.
>
> You can see the Mine_Detector code in Gnoga's demo directory.
>
I took a look. It looks like your entry is actually "per connection"
unless I misunderstand. Your app data structure has the serializer as part
of the record. Doesn't that mean that each connection gets their own
serializer?
------------------------------------------------------------------------------
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
