On 9-4-2017 21:33, Adriano dos Santos Fernandes wrote:
> Vlad,
>
> I think have found the problem in server.
>
> Look at this:
>
> --------
> ISC_STATUS rem_port::que_events(P_EVENT * stuff, PACKET* sendL)
> {
> ...
>
> Rvnt* event;
> for (event = rdb->rdb_events; event; event = event->rvnt_next)
> {
> if (!event->rvnt_iface)
> {
> event->rvnt_destroyed = 0;
> break;
> }
> }
>
> if (!event)
> {
> event = FB_NEW Rvnt;
> #ifdef DEBUG_REMOTE_MEMORY
> printf("que_events(server) allocate event %x\n",
> event);
> #endif
> event->rvnt_next = rdb->rdb_events;
> rdb->rdb_events = event;
> event->rvnt_callback = FB_NEW Callback(rdb, event);
> }
> --------
>
> This code runs concurrently and find the same empty slot for
> simultaneous events being registered.
In the specific example, Jaybird uses a single connection to register
for events, and it takes a lock on the database handle, so there
wouldn't be concurrent que_events invocations on that connection. Is it
possible that a similar problem occurs when que_events call interleaves
with an even notification being posted back to the client?
Mark
--
Mark Rotteveel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
