Is there any Non-blocking IO open source implementation for Scala's actors?

前端 未结 4 555
臣服心动
臣服心动 2020-12-31 17:49

I have quite large files that I need to deal with (500Meg+ zip files).

Are there any non-blocking IO open source implementations for Scala\'s actors?

相关标签:
4条回答
  • 2020-12-31 17:53

    Not that I know of, but you could probably get a lot of mileage out of looking at Naggati, a Scala wrapper around Apache Mina. Mina is a networking library that uses NIO, Naggati translates this into a Scala style of coding.

    0 讨论(0)
  • 2020-12-31 17:57

    Hello is that an option for you? bigdata(R) is a scale-out storage and computing fabric supporting optional transactions, very high concurrency, and very high aggregate IO rates.

    http://sourceforge.net/projects/bigdata/

    0 讨论(0)
  • 2020-12-31 18:03

    Are you talking about Remote actors? A standard Actor is of course a intra-JVM entity. I'm not aware of an NIO implementation of remote actors I'm afraid.

    0 讨论(0)
  • 2020-12-31 18:15

    If I got your question right, you need non-blocking IO for files. I have bad news for you then.

    NIO

    Java NIO in Java6 supports only blocking operation when working with files. You may notice this from the fact FileChannel does not implement SelectableChannel interface. (NIO does support non-blocking mode for sockets however)

    There is NIO.2 (JSR-203) specification aimed to overcome many current limits of java.io and NIO and to provide support for asynchronous IO on files as well. NIO.2 is to be released with Java 7 as far as I understand.

    These are Java library limits, hence you will suffer from them in Scala as well.

    Actors

    Actors are based on Fork-Join framework of Doug Lea (at least in branch 2.7.x till version 2.7.7). One quote from FJTask class:

    There is nothing actually preventing you from blocking within a FJTask, and very short waits/blocks are completely well behaved. But FJTasks are not designed to support arbitrary synchronization since there is no way to suspend and resume individual tasks once they have begun executing. FJTasks should also be finite in duration -- they should not contain infinite loops. FJTasks that might need to perform a blocking action, or hold locks for extended periods, or loop forever can instead create normal java Thread objects that will do so. FJTasks are just not designed to support these things.

    FJ library is enhanced in Scala to provide a unified way permitting an actor to function like a thread or like an event-based task depending on number of working threads and "library activity" (you may find explanation in technical report "Actors that unify Threads and Events" by Philipp Haller and Martin Odersky).

    Solution?

    But after all if you run blocking code in an actor it behaves just like if it being a thread, so why not use an ordinary Thread for blocking reads and to send events to event-based actors from this thread?

    0 讨论(0)
提交回复
热议问题