With callbacks you will smear code over two methods: caller, callback.
Also you will need to keep some state! AFAIU coroutins solve this
problem in more elegant manner using saving running context. Operator
A push a portion of data to pipe and *goto* operator B which pull the
portion process it and
26.10.2016 16:41, Adriano dos Santos Fernandes wrote:
> We can't *callback* our caller.
Why not? It is a matter of adding one method to your new API:
class IEater
{
int pushData(IMessageMetadata* metadata, void* buffer);
};
IStatus* IAttachment::execute(const char* SQL, IMessageMetada
On 26/10/2016 12:22, Egor Pugin wrote:
> Why not callbacks?
>
>
When things start, it's the user who calls the engine and expects the
engine to *return*, then user resumes the engine.
We can't *callback* our caller.
Adriano
--
Why not callbacks?
On 26 October 2016 at 15:51, Roman Simakov wrote:
> 2016-10-26 15:24 GMT+03:00 Dimitry Sibiryakov :
>> It must be more than just nice to add gigabyte of boost sources or 30
>> megabytes library
>> to Firebird
>
> I guess it's not about boost but about approach. I thought abou
2016-10-26 15:24 GMT+03:00 Dimitry Sibiryakov :
> It must be more than just nice to add gigabyte of boost sources or 30
> megabytes library
> to Firebird
I guess it's not about boost but about approach. I thought about the
same approach in SciDB to provide nice way to implement new operators
in
26.10.2016 13:33, Adriano dos Santos Fernandes wrote:
> This is so nice (and apparent fast in Linux) that I'm going to
> investigate further.
It must be more than just nice to add gigabyte of boost sources or 30
megabytes library
to Firebird.
--
WBR, SD.
---
Hi!
Learning node.js and its single-threaded model with asynchronous
execution, I looked for things that can improve Firebird as well.
It's obvious that things like boost asio may be a good thing when
dealing with sockets and filesystem, but is not subject of this thread.
Today I got up thinking