Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reactive Streams discussion #878

Open
nickwongdev opened this issue Dec 18, 2018 · 1 comment
Open

Reactive Streams discussion #878

nickwongdev opened this issue Dec 18, 2018 · 1 comment

Comments

@nickwongdev
Copy link

Howdy,

I'm new to the project but I have built several reactive projects in Java with Rx1, 2, and now Reactor, and Reactor Spring. Given Pivotal's backing and simpler semantics than Rx, Project Reactor seems to be pretty well positioned to become the defacto Java implementation of Reactive Streams. Rx will continue but not as prolifically as Reactor. This adoption includes the Java implementation of RSocket its self.

I've looked at a few implementations of reactive programming on c++, but I haven't seen one that follows the Mono, Flux, if there is one please let me know.

If there isn't a Project Reactor allegory on c++, I believe it is advantageous and strategic to take yarpl, rename a few pieces to follow Java's Reactor implementation and semantics. This would have advantages for cross language RSocket developers like me. I believe this would also solve the naming issue. Counter argument might be that Boost or Folly might implement a more ubiquitous implementation of Reactive Streams for C++, meaning the MVP of yarpl was intentional while we wait for a larger org to produce a standard.

By opening the issue, I'm really just trying to get an idea for the maintainer's appetite for having cross language semantics follow Project Reactor. Especially considering the project already decided to make their own custom implementation of Reactive Streams.

Thanks for your time,

Nick
@OlegDokuka
Copy link
Member

I would suggest picking the part of the reactive-streams interfaces out and unify it first as a part of Reactive Streams specifications repository and then maintain the particular implementation which is compliant with the spec

facebook-github-bot pushed a commit that referenced this issue Dec 21, 2020
@arhelmus @facebook-github-bot
Forced watchman daemon to always operate in non elevated mode on Wind…
c3600d4 
…ows (#878)

Summary:
Recently I found that its impossible to access elevated Watchman daemon from non-elevated process on Windows.

```
events.js:174
      throw er; // Unhandled 'error' event
      ^
Error: connect EPERM \\.\pipe\watchman
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1106:14)
Emitted 'error' event at:
    at Socket.<anonymous> (C:\open\ovrsource\unity\socialvr\_js\node_modules\fb-watchman\index.js:118:12)
    at Socket.emit (events.js:198:13)
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at process._tickCallback (internal/process/next_tick.js:63:19)
```

To fix this, it was suggested by wez to use [his library](https://github.com/wez/EleDo) to force Watchman daemon always start in normal mode on Windows. In this stack of commits I did integrated his library into project and used it to force daemon restart in normal mode when spawned from elevated terminal.

To make it happen, I checked-in library sources and created proxy project which depends on the initial library and contains header bindings and cmake configuration. I did copy pasted Rust cmake macroses from another facebook project - eden, and also created analogue of autogen.sh but for Windows - autogen.cmd.

Pull Request resolved: facebook/watchman#878

Test Plan:
Launch elevated terminal
Start watchman.exe produced from sources
Observe daemon starting and answering
In process monitor, observe watchman.exe process running under user group

Reviewed By: fanzeyi

Differential Revision: D25595879

Pulled By: arhelmus

fbshipit-source-id: 15eb29adcf5bd4a5708b6533a1b2bacbf13f431c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nickwongdev @OlegDokuka