Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Fabio Labella
@SystemFw
they might work
they are also considered unsafe (and dangerous)
Oleg Pyzhcov
@oleg-py
Oh, there's also subprocessing
Jules Ivanic
@guizmaii
If I meet some of you one day, I’ll pay you a beer or two ! You’re always here or there to help me. Thanks a lot :)
Jules Ivanic
@guizmaii
in fact the AtomicBoolean trick can maybe do the job. #excited :smile:
Damian Reeves
@DamianReeves
Hi. Does monix provide any utility for going from a Java Future to a scala Future or a monix Task?
toxicafunk
@toxicafunk
i'm pretty sure there was an fromFuture either on task or on observable
Damian Reeves
@DamianReeves
yeah that is for a scala future
Best I can think to do is top wrap the polling required with a task, but this feels like it should exist already somewhere
toxicafunk
@toxicafunk
oh sorry, I misread
need to check if this got implemented though
Damian Reeves
@DamianReeves
thanks for pointing to the issue... unfortunately I'm stuck with scala 2.11 for the time being
Aleksandr Melnikov
@amelnikov-mylivn

Hello. I wolnder if monix 3.0.0-RC1 is compatiable with cats 1.4.0 and cats-effect 1.0.0?
I got two wierd exceptions:

java.lang.AbstractMethodError: Method monix/eval/instances/CatsConcurrentForTask$.bracketCase(Ljava/lang/Object;Lscala/Function1;Lscala/Function2;)Ljava/lang/Object; is abstract
    at monix.eval.instances.CatsConcurrentForTask$.bracketCase(CatsAsyncForTask.scala)
    at cats.effect.Bracket.bracket(Bracket.scala:64)
    at cats.effect.concurrent.Semaphore$AbstractSemaphore.withPermit(Semaphore.scala:244)

and

java.lang.ClassCastException: monix.eval.Task$Eval cannot be cast to cats.effect.IO
    at monix.eval.internal.TaskEffect$.$anonfun$cancelable$1(TaskEffect.scala:59)
    at monix.eval.internal.TaskEffect$.$anonfun$cancelable$1$adapted(TaskEffect.scala:52)
    at monix.eval.internal.TaskRunLoop$.executeAsyncTask(TaskRunLoop.scala:421)
    at monix.eval.internal.TaskRunLoop$.startFull(TaskRunLoop.scala:110)
    at monix.eval.internal.TaskRunLoop$RestartCallback.onSuccess(TaskRunLoop.scala:537)
    at monix.eval.internal.TaskRunLoop$.startFull(TaskRunLoop.scala:117)
    at monix.eval.internal.TaskMemoize$Register.$anonfun$registerListener$1(TaskMemoize.scala:132)
    at monix.eval.internal.TaskMemoize$Register.$anonfun$registerListener$1$adapted(TaskMemoize.scala:129)
    at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
I got this error after I added Semaphore[Task, Unit] usage in my code
Aleksandr Melnikov
@amelnikov-mylivn
Oh now I see that cats-effect 1.0.0 support is planned for 3.0.0-RC2
Googled by exceptions so missed this monix/monix#710
BTW it does not work with 3.0.0-RC2-d0feeba either
Oleg Pyzhcov
@oleg-py
@DamianReeves IIRC I made it so that monix-java just supports scala 2.11 in the end
Damian Reeves
@DamianReeves
thanks. will be helpful for those of us stuck in the past.
Alexander Khotyanov
@aksharp
@guizmaii a coworker had same exact problem today - canceling tasks/futures, although he's working with an app that uses futures and he used this as a guide to his solution https://viktorklang.com/blog/Futures-in-Scala-protips-6.html
Jules Ivanic
@guizmaii
@aksharp Thanks. I’ll take a look :)
Mateusz Górski
@goral09
@oleg-py @Avasil @alexandru I am looking for a place in the monix runLoop that imitates the green thread management. The docs say that operations are semantically blocking (no thread is blocked) so there must be logic that deals with yielding and resuming the work.
Oleg Pyzhcov
@oleg-py
@goral09 it's spread across TaskCreate, TaskRestartCallback and TaskRunLoop somewhat. There's no concept of green thread in the code, all it does is use Scheduler to, well, schedule the continuation.
Mateusz Górski
@goral09
Thanks @oleg-py
Oleg Pyzhcov
@oleg-py
Eventually, it boils down to usage of java's ScheduledExecutionService or plain JS setTimeout for scheduling
Fabio Labella
@SystemFw
@goral09 the implementation of green threading in monix and cats-effect is different from the one in scalaz
in scalaz IO, there is an actual type for a green thread, and IOs are scheduled manually by the runloop (with round robin last time I checked, but that was a while ago)
otoh monix and cats-effect just schedule the continuation by relying on the JVM (or JS) native tools
and they yield at async boundaries
and therefore Fiber here is just a "view" over the running computation, allowing you to wait on it (join) or interrupt it (cancel)
Fabio Labella
@SystemFw

and they yield at async boundaries

well, I guess earlier than that, since it's trampolined as well

Alexandru Nedelcu
@alexandru
The implementation of Scalaz IO cannot be that different, since it has to rely on the same primitives.
Fabio Labella
@SystemFw
I think at some point it actually wanted to move away from EC altogether
Mateusz Górski
@goral09
in theory, it (scalaz's) should be faster
Alexandru Nedelcu
@alexandru
Why do you say that?
Mateusz Górski
@goral09
because it doesn't have to go to EC and back?
Fabio Labella
@SystemFw

in theory, it (scalaz's) should be faster

citation needed

and also it does use an EC right now
Alexandru Nedelcu
@alexandru

"Green threads" basically means units of work that do "cooperative multi-threading", which effectively means some way to execute multiple things without necessarily scheduling those on separate OS threads.

An executing Task or IO is essentially a "green thread".

Nothing magical about it.
Mateusz Górski
@goral09
yes, I get that part @alexandru , I was interested seeing in actual mechanics of how this is managed
Alexandru Nedelcu
@alexandru
When you end up with a "run loop" like we have, you've essentially overriden Java's call-stack, which means you have a green threads implementation on your hands.
Well, yeah, it's in TaskRunLoop. It's not going to be easy to read though, due to all the speed improvements.
Fabio Labella
@SystemFw
it's not that bad once you get used to the style
and all the "ugliness" is 100% necessary there
all the implementations have a similar strategy at the core: a current IO[Any], and a Stack[Any => IO[Any]]]
the runloop really is a run...loop
in Zio you have this bit of code
Mateusz Górski
@goral09
I wonder it this choice was an informed one (from scalaz-io RTS) :
val threadPool = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors().max(2))