The best approach would probably be to rethink your logic to be fully
asynchronous. You should not ever need to wait for results; you should
always do the following actions in further ->then callbacks, or use
Mojo::Promise->all or similar to make promises that wait for several other
promises.
-Dan
This is gold:
*"You need to use the same event loop for the promise as for the items that
will resolve it"*
Thanks Dan!
The posted action is just for demo my problem. I actually want to use a
loop to do something like:
# inside a timer callback
my $more_jobs = 1;
while ($more_jobs) {
$get_jo
But to add, there's usually no reason to make it this complicated; if you
just use the main event loop, and do your rendering in a ->then chained off
the promise, you don't need to wait for it; it will render the page when
the promise resolves.
On Thu, Mar 15, 2018 at 12:34 AM, Dan Book wrote:
>
You need to use the same event loop for the promise as for the items that
will resolve it. So for instance in your example you need to do:
my $loop = Mojo::IOLoop->new;
my $promise = Mojo::Promise->new(ioloop => $loop);
$loop->timer(...);
return $promise;
On Wed, Mar 14, 2018 at 11:34 PM, Michael
Hi Dan,
It does not work, perhaps I misunderstood you.
Here is my action for test:
sub boom {
my ($c) = @_;
my @output;
my $timer = sub {
#~ my $promise = Mojo::Promise->new;
my $promise = Mojo::Promise->new(ioloop => Mojo::IOLoop->new);
Mojo::IOLoop->timer
While using Pg and SQLite backends, job ids are generated as incremental
> integers.
>
> This ordering characteristic would come very handy in one application I'm
> writing. Is it something dependable, or should I consider ids as opaque for
> future-proofness?
>
While it seems unlikely that ids in
->wait will not block if the event loop is currently running, like if you
are setting this up in an event loop callback like a request handler. In
order to cause promises to block while running the main event loop, you
need to run the promises in a separate event loop.
my $promise = Mojo::Promise-
Thanks Andre. I already have the "return $promise" statement to end the
sub, so it is not the cause.
I really suppose the construct will work like the recv function of AnyEvent
->condvar.
On Wednesday, March 14, 2018 at 9:11:53 PM UTC+8, Andre Parker wrote:
>
> Hi.
>
> You should return promis
Hi.
You should return promise object in get_data sub. Something like:
my $get_data = sub {
my $promise = Mojo::Promise->new();
# Some code that resolves promise
...
return $promise;
};
On Wednesday, 14 March 2018 12:18:07 UTC+2, Michael Fung wrote:
>
> Hi all,
>
> I have the following co
>
> While using Pg and SQLite backends, job ids are generated as incremental
> integers.
>
> This ordering characteristic would come very handy in one application I'm
> writing. Is it something dependable, or should I consider ids as opaque for
> future-proofness?
>
While it seems unlikely tha
Hi all,
I have the following construct using Mojo::Promise:
my $get_data = sub {
create new Promise object;
read data from database
if data read ok {
$promise->resolve($data);
} else {
$promise->reject('no data');
}
};
$get_data->()
->then( sub {
# do something with data
Hi!
While using Pg and SQLite backends, job ids are generated as incremental
integers.
This ordering characteristic would come very handy in one application I'm
writing. Is it something dependable, or should I consider ids as opaque for
future-proofness?
To avoid the XY problem, some backgrou
12 matches
Mail list logo
