Distributed system development with ScalaLoci

Weisenburger, Pascal; Köhler, Mirko; Salvaneschi, Guido

doi:10.1145/3276499

Cited by 39 publications

(49 citation statements)

References 64 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Fault-tolerant Distributed RP introduces error propagation and crash recovery for reactives and executes updates glitch-free by mutual exclusion on each host, but supports distribution only through conflict-free replicated data types with eventual consistency and therefore supports some concurrency in the global propagation, but only with eventual consistency instead of glitch freedom. (F)RP has been also studied in combination with multitier programming for distributed applications in ScalaLoci [Weisenburger et al 2018] and tailored towards web applications [Reynders et al 2014]; these works allow reactives of arbitrary types to be sent to different hosts, but focus on the language design benefits and synergies of multitier and reactive programming instead of solving consistent distributed propagation, and therefore also only execute updates glitch-free by mutual exclusion per host, but do not provide glitch freedom across the whole application.…”

Section: Discussionmentioning

confidence: 99%

Thread-safe reactive programming

Drechsler

Mogk

Salvaneschi

et al. 2018

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

The execution of an application written in a reactive language involves transfer of data and control flow between imperative and reactive abstractions at well-defined points. In a multi-threaded environment, multiple such interactions may execute concurrently, potentially causing data races and event ordering ambiguities. Existing RP languages either disable multi-threading or handle it at the cost of reducing expressiveness or weakening consistency. This paper proposes a model for thread-safe reactive programming (RP) that ensures abort-free strict serializability under concurrency while sacrificing neither expressiveness nor consistency. We also propose an architecture for integrating a corresponding scheduler into the RP language runtime, such that thread-safety is provided łout-of-the-boxž to the applications.We show the feasibility of our proposal by providing and evaluating a ready-to-use implementation integrated into the REScala programming language. The scheduling algorithm is formally proven correct. A thorough empirical evaluation shows that reactive applications build on top of it scale with multiple threads, while the scheduler incurs acceptable performance overhead in a single-threaded configuration. The scalability enabled by our scheduler is roughly on-par with that of hand-crafted application-specific locking and better than the scalability enabled by a scheduler using an off-the-shelf software transactional memory library. 1 We chose REScala, because its API is designed to support different backend runtimes.Thread-Safe Reactive Programming 107:3 with that of hand-crafted application-specific locking, and better while also providing stronger guarantees than a scheduler using an off-the-shelf Software Transactional Memory library. ğ2 introduces RP concepts from the user perspective, ğ6 positions our approach with respect to related work, and ğ7 concludes the paper and discusses areas of future work. REACTIVE PROGRAMMING IN RESCALAWe introduce (single-threaded) RP from the developer's perspective by implementing an example application in REScala. Our design is inspired by the dining philosophers [Hoare 1985], with philosophers sharing forks around a table. We later introduce concurrency and discuss its effects through multiple threads concurrently executing updates for different philosophers. For flexibility in later examples and benchmarks, the table's SIZE (number of philosophers and forks) is parametric. The User PerspectiveWe introduce Events, Signals, conversions between them and their imperative interactions.Signals. Philosophers are modelled as Vars of type Phil, initially in state Thinking. 1 cases Phil = { Thinking, Eating } 2 val phils = for (j <− 1 until SIZE) yield Var[Phil](Thinking)A REScala Var is a kind of mutable variable. Like ordinary variables, the value of a Var can be read (through now, e.g., phils(1).now reads the current value of the philosopher with index 1) and overwritten (through set(...), e.g., phils(1).set(Eating)). Unlike ordinary variables, changes of Vars are autom...

show abstract

Section: Discussionmentioning

confidence: 99%

Thread-safe reactive programming

Drechsler

Mogk

Salvaneschi

et al. 2018

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

show abstract

“…In a web settings, for example if input validation is done on the server, then these semantics require that input from the client is transmitted to the server, validated and transmitted back, all in the same propagation, so that the client and server both block until everything is finished. To combat these issues, projects such as DREAM [16] and ScalaLoci [35] make these algorithms pluggable, but none have tiered glitch freedom as an option.…”

Section: Total Glitch Freedommentioning

confidence: 99%

“…Regarding multi-tier languages, we look at languages that are based on existing languages such as Eliom [23] (OCaml), ScalaLoci [35] (Scala), Hop [29,31] (Scheme), HopJS [30,33] (JavaScript) and Flask [15] (Haskell) as well as languages that are built from scratch such as Ur/Web [6,5] and AmbientTalk/R [4].…”

Section: Related Workmentioning

confidence: 99%

“…Distributed reactive programming languages [11,16,18] have distributed consistency guarantees and allow distributed FRP propagation without observable partial propagations (glitches). ScalaLoci [35] in particular -a general purpose multi-tier extension of Scala which allows programmers to define their own distribution schemesupports tier-crossing primitives with distributed consistency guarantees. These guarantees are gained through a compromise of using global coordination or increasing message count or size.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Gavial: Programming the web with multi-tier FRP

2020

View full text Add to dashboard Cite

Web applications are inherently distributed, and not just because their client and server counterparts run on networked systems. Web applications are written in multiple programming languages and as multiple programs: the server and client programs. In an effort to lower the complexity of the web, multi-tier programming was proposed. In multi-tier programming languages the language and its tooling give support to create web applications as a whole, one program is written in one language.Web applications are also inherently asynchronous. On the server, they constantly process several client requests and in the browser they constantly have to react to input, be it from the user or a server. A technique that can be applied to make such programs easier to understand is functional reactive programming. A functional programming model that models an interactive program as compositions between two primitives, behaviors and events.Developing web applications requires dealing with their distributed nature and the natural asynchronicity of user input and network communication. For facilitating this, different researchers have explored the combination of a multi-tier programming language and functional reactive programming. However, existing proposals take his approach only part of the way. Some parts of the application remain imperative, do not consider network traffic overhead of incremental data, compatibility with common APIs like XMLHttpRequest etc., or they do not consider glitches across network communication (or do but introduce locking or overhead)In this paper, we present Gavial: a design and practical implementation of multi-tier FRP that allows constructing a web application as a functionally reactive program. We propose a novel integration of existing techniques such as solutions to bootstrapping web applications, recursive behaviors for web interfaces, asynchronous FRP and incremental behaviors. As well as novel support for tiered glitch freedom, a compromise between performance and glitch-free evaluation of the distributed FRP program, and a three-tiered system suitable for request-response-style applications as well as user-to-user applications. Gavial automatically runs in request-response (XMLHttpRequest) mode or in websocket mode.After applying a number of old and new ideas to create a practical multi-tier FRP implementation in Gavial, we demonstrate it by building an example and show that it can in fact deal realistically with important practical aspects of building web applications. At the same time, we retain the declarative nature of FRP, where behaviors and events have an intuitive, compositional semantics and a clear dependency structure. ACM CCS 2012Listing 2 Delayed DBehavior object DBehavior { def delayed[A](db: ⇒ DBehavior[A]): Behavior[A] }Returning to CircleRoyale, a type Player represents a player's position, and whether he is alive, attacking or dead. The svg method produces the player's circle and optionally the attacking circle as SVG elements. case class Player(position: Vec2D, attacking: ...

show abstract

“…Having defined the components and their architectural relation using peer types, developers can place values on the different peers through placement types [60]. The 17:5 placement type T on P 2 represents a value of type T on a peer P. Placed values are initialized by placed { e } expressions.…”

Section: Scalaloci In Nucementioning

confidence: 99%

Implementing a Language for Distributed Systems: Choices and Experiences with Type Level and Macro Programming in Scala

Weisenburger

Salvaneschi

2020

Programming

Self Cite

View full text Add to dashboard Cite

Multitier programming languages reduce the complexity of developing distributed software by developing the distributed system within a single coherent code base. In multitier languages, the compiler or the runtime takes care of separating the code into the components of the distributed system. This approach enables abstraction over low level implementation details such as data representation, serialization and network protocols. The ScalaLoci programming language allows developers to declare the components of the system and their architectural relation at the type level, enabling static reasoning about distribution and remote communication and guaranteeing static type safety for data transfer across components. As the compiler automatically generates the communication boilerplate among components, data transfer among components can be modeled declaratively, by specifying the data flows in the reactive programming style.In this paper, we report on the ScalaLoci implementation and on our experience with embedding ScalaLoci's language features into Scala as a host language. We show how a combination of Scala's advanced type level programming and of Scala's macro system enable enriching the language with new abstractions for distributed systems. We describe the challenges we encountered for the implementation and report on the solutions we developed. Finally, we outline suggestions for improving the Scala macro system to better support embedding domain-specific abstractions. ACM CCS 2012The design of ScalaLoci unfolds around three major ideas. First, the distributed topology (i.e., separate locations that execute code) is explicit and specified by the programmer, who assigns code to each system component. Second, remote communication within the distributed system (i.e., with performance and failure characteristics different from local communication) is explicit and supports event-based interaction between components. Third, ScalaLoci abstractions are embedded as domain-specific features into an existing general purpose language. We lay out the design space for our language implementation and derive concrete design requirements.Explicit Specification of Distribution and Topology Some languages for distributed systems abstract over the topology, i.e., code is agnostic to the system's components and their connections. Such approach is often chosen for highly specialized programming models, e.g., streaming systems [16,62], intentionally hiding distribution. On the other end lie approaches where developers specify the topology. Distribution unavoidably becomes apparent when implementing different components, e.g., in actor systems [1]. While actor systems encapsulate components into actors, topological information is not encoded at the language level but managed explicitly by the developer.Clearly, a multitier programming model for developing generic distributed systems -similar to what the actor model offers -cannot abstract over distribution completely. To decide on the component that executes a specific part of the cod...

show abstract

Distributed system development with ScalaLoci

Cited by 39 publications

References 64 publications

Thread-safe reactive programming

Thread-safe reactive programming

Gavial: Programming the web with multi-tier FRP

Implementing a Language for Distributed Systems: Choices and Experiences with Type Level and Macro Programming in Scala

Contact Info

Product

Resources

About