28.08.2017 12:49, Slavomir Skopalik wrote:
And by the way, Embarcadero in delphi IBX code don't counted with that.
FIBC and all derivates has the worst event component that I've ever seen. It can work
only in simplest cases and only by stupid luck.
--
WBR, SD.
But this mean to have some global dispatcher that will die as last
object during termination process.
This is far from clean programing.
And by the way, Embarcadero in delphi IBX code don't counted with that.
Slavek
28.08.2017 11:09, Paul Reeves wrote:
The event listener should really be
28.08.2017 12:40, Slavomir Skopalik wrote:
there are two different situation:
1. cancel is call from different thread
2. cancel is called from call back
You don't need (and actually, cannot) cancel events from callback.
Why this:
If you are create a object that wraps this interface,
Thread is created inside gds32.dll.
Slavek
Maybe I'm missing something, but I seem to recall from the code that
you posted that your listener is running on a timer in the main thread.
The event listener should really be running in its own thread.
Have you tried that?
Paul
28.08.2017 11:09, Paul Reeves wrote:
The event listener should really be running in its own thread.
Actually, callback is already called in its own thread. If a programmer is aware of
that and coded it properly - there is no problem with extra calls.
--
WBR, SD.
On Mon, 28 Aug 2017 11:01:16 +0200 Slavomir Skopalik wrote
> >
> > On 28.08.2017 04:15, Slavomir Skopalik wrote:
> >> Should I create ticket for this?
> >>
> >
> > No. Removing that call will break old code.
>
> You mean, old code will not crash so often.
> How much time I have to wait to
28.08.2017 3:15, Slavomir Skopalik wrote:
From programing theory, no call back after successful cancel event is allowed.
From your theory, how should be thread waiting with isc_event_wait() to be aborted
without calling callback on cancel?
--
WBR, SD.
28.08.2017 11:01, Slavomir Skopalik wrote:
How much time I have to wait to be sure that no more call back?
Or is there other technique how to solve it?
Yes: ritht callback routine can only set flags. In any case it can call (almost)
nothing from ISC API and have to return ASAP.
--
WBR,
On 28.08.2017 04:15, Slavomir Skopalik wrote:
Should I create ticket for this?
No. Removing that call will break old code.
You mean, old code will not crash so often.
How much time I have to wait to be sure that no more call back?
Or is there other technique how to solve it?
From
On 28.08.2017 04:15, Slavomir Skopalik wrote:
Should I create ticket for this?
No. Removing that call will break old code.
From programing theory, no call back after successful cancel event is
allowed.
To be precise - it happens during event cancellation.
Slavek
Hi all,
I'm testing
Should I create ticket for this?
From programing theory, no call back after successful cancel event is
allowed.
Slavek
Hi all,
I'm testing Firebird-3.0.3.32798-0_Win32 client and I found strange
behavior when I canceling event
by isc_cancel_events.
I supposed that after that call, no
Not exactly,
procedure EventCallback(P: Pointer; Length: Short; Updated: PByte); cdecl;
var e:TFBEvents;
begin
if (Assigned(P) and Assigned(Updated)) then begin
e:=TFBEvents(p);
try
e.FSO.Enter;
e.EventsReceived := true;
if e.ResultBuffer<>nil then
On 25.08.2017 13:36, Slavomir Skopalik wrote:
Hi all,
I'm testing Firebird-3.0.3.32798-0_Win32 client and I found strange
behavior when I canceling event
by isc_cancel_events.
I supposed that after that call, no call back happen, but in reality
it is happen.
Is it correct?
One
But I'm talking about fbclient.dll.
It is problematic, because in that concept mean, one times when you give
a call back address.
fbclient can call any time during application run independently to
isc_cancel_event.
I did see any problem with second channel. In normal model when I
> I supposed that after that call, no call back happen, but in reality it
> is happen.
>
> Is it correct?
I'd say it is (I have the same in FirebirdClient during tests under
load) and even understandable. Given by design it's 2nd "channel" and
the processing between regular connection and aux
Hi all,
I'm testing Firebird-3.0.3.32798-0_Win32 client and I found strange
behavior when I canceling event
by isc_cancel_events.
I supposed that after that call, no call back happen, but in reality it
is happen.
Is it correct?
Slavek
--
Ing. Slavomir Skopalik
Executive Head
Elekt Labs
16 matches
Mail list logo
