And Dmitry thank you for enforcing review of that code. Looks like I've
found races during that review.
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databa
On 03/18/2014 08:15 PM, Dimitry Sibiryakov wrote:
> 18.03.2014 13:30, Alex wrote:
>> The main reason is an ability to delete provider's object better sooner
>> than later.
>> - yvalve object is tiny and consumes very low resources
>> - provider's object may be relatively big
> But they both are
On 03/18/2014 06:58 PM, Jim Starkey wrote:
> Do you really use a mutex to when walking a structure Why not a
> read/write lock? With a mutex, readers block readers, which is a total
> waste of cycles, thread stalls, thread switches, etc.
>
That mutex is also needed to increment thread enter
> -Original Message-
> From: Alex [mailto:peshk...@mail.ru]
> Sent: Miércoles, 19 de Marzo de 2014 1:16
> >>>
> Adriano:
> >> Why the engine error message about unsupported DYN is not
> sufficient?
>
> Steve:
> > < and discovering that
> > the DDL doesn't work when you compile the preproc
On 03/18/2014 08:52 PM, Paul Beach wrote:
>> On 18/03/2014 13:09, Claudio Valderrama C. wrote:
>>> People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
>>> FB3 doesn't understand DYN. What should we do, disable
>> those places in GPRE
>>> with an error message?
>>>
>>>
>> Why the engi
> On 18/03/2014 13:09, Claudio Valderrama C. wrote:
> > People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
> > FB3 doesn't understand DYN. What should we do, disable
> those places in GPRE
> > with an error message?
> >
> >
> Why the engine error message about unsupported DYN is n
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Martes, 18 de Marzo de 2014 11:25
>
> On 18/03/2014 13:09, Claudio Valderrama C. wrote:
> > People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
> > FB3 doesn't understand DYN. Wha
On 18/03/2014 12:28, Steve Boyd wrote:
> Because it would be nice to know at compile time that there is an
> issue rather than at run time.
>
But GPRE is client tool, and who may not accept the command is the server.
So if GPRE is going to parse the command and reject it without reason, I
would p
18.03.2014 13:30, Alex wrote:
> The main reason is an ability to delete provider's object better sooner
> than later.
> - yvalve object is tiny and consumes very low resources
> - provider's object may be relatively big
But they both are on client side. As you said, client's memory consumption
Because it would be nice to know at compile time that there is an issue
rather than at run time.
On 03/18/14 11:24 AM, Adriano dos Santos Fernandes wrote:
On 18/03/2014 13:09, Claudio Valderrama C. wrote:
People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
FB3 doesn't understand
On 18/03/2014 13:09, Claudio Valderrama C. wrote:
> People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
> FB3 doesn't understand DYN. What should we do, disable those places in GPRE
> with an error message?
>
>
Why the engine error message about unsupported DYN is not sufficient?
A
People, GPRE's cmd.cpp and sql.cpp generate a lot of DYN commands.
FB3 doesn't understand DYN. What should we do, disable those places in GPRE
with an error message?
C.
---
Claudio Valderrama C.
Consultant, SW developer.
---
On 3/18/2014 7:47 AM, Alex wrote:
> On 03/18/2014 01:26 PM, Dimitry Sibiryakov wrote:
>> Back to the question:
>>
>> 17.03.2014 12:30, Alex Peshkoff wrote:
Besides, storing reference to object already increment its
> usage counter, so nobody can free the object during wrapper's l
On 03/18/2014 04:11 PM, Dimitry Sibiryakov wrote:
> 18.03.2014 12:47, Alex wrote:
>> IAttachment* userHandle points to class YAttachment, containing (among
>> others) reference counter and reference pointer to IAttachment next.
>> Let's take into an account that on successful detach next is nullifi
18.03.2014 12:47, Alex wrote:
> IAttachment* userHandle points to class YAttachment, containing (among
> others) reference counter and reference pointer to IAttachment next.
> Let's take into an account that on successful detach next is nullified,
> and if other references are present (i.e. YAttach
On 03/18/2014 01:26 PM, Dimitry Sibiryakov wrote:
> Back to the question:
>
> 17.03.2014 12:30, Alex Peshkoff wrote:
>>> Besides, storing reference to object already increment its
usage counter, so nobody can free the object during wrapper's life time.
>> But using something like commi
Back to the question:
17.03.2014 12:30, Alex Peshkoff wrote:
>>Besides, storing reference to object already increment its
>> >usage counter, so nobody can free the object during wrapper's life time.
> But using something like commit for transaction can nullify next pointer.
next is a re
17 matches
Mail list logo
