On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote:
I added a tag for iopipe and added it to the dub registry so people can try it out.

I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe

Great news to see continued work on this.

I'll just use this thread to get started on design discussions. If there is there a better place for that, let me know ;).

Questions/Ideas

- You can move docs out of the repo to fix search, e.g. by pushing them to a `gh-pages` branch of your repo. See https://github.com/MartinNowak/bloom/blob/736dc7a7ffcd2bbca7997f273a09e272e0484596/travis.sh#L13 for an automated setup using Travis-CI and ddox/scod.

- Standard device implementation?

You library already has the notion of devices as thin abstractions over file/socket handles. Should we start with such an unbuffered IO library as foundation including support hooks for Fiber based event loops. Something along the lines of https://code.dlang.org/packages/io? Without a standard device lib, IOPipe could not be used in APIs.

  Easy enough to write, could be written over a weekend.

- What's the plan for @safe buffer/window invalidation, right now you're handing out raw access to internal buffers with an inherent memory safety problem.

  ```d
  auto w = f.window();
  f.extend(random());
  w[0]; // ⚡ dangling pointer ⚡
  ```

I can see how the compiler could catch that if we'd go with compile-time enforced safety for RC and friends. But that's still unclear atm. and we might end up with a runtime RC/weak ptr mechanism instead, which wouldn't be too good a fit for that window mechanism.

- What about the principle that the caller should choose allocation/ownership? Having an extend methods means the IOPipe is responsible for growing/allocating buffers, so you'll end up with IOPipeMalloc, IOPipeGC, IOPipeAllocatorGrowExp (or their template alternatives), not very nice for APIs.

- Why continuous memory? The current implementations reallocs and even weirder memmoves data in extend. https://github.com/schveiguy/iopipe/blob/3589a4c9fc72b844eb4efd3ae718773faf9ab9ed/source/iopipe/buffer.d#L171
  Shouldn't a modern IO library be as zero-copy as possible?
The docs say random access, that should be supported by ringbuffers or lists/arrays of buffers. Any plans towards that direction?

            • Re: ... Steven Schveighoffer via Digitalmars-d-announce
              • ... Suliman via Digitalmars-d-announce
              • ... Martin Nowak via Digitalmars-d-announce
              • ... Martin Nowak via Digitalmars-d-announce
  • Re: iopipe alpha 0.0.1 ver... Jacob Carlborg via Digitalmars-d-announce
  • Re: iopipe alpha 0.0.1 ver... Martin Nowak via Digitalmars-d-announce
    • Re: iopipe alpha 0.0.... Steven Schveighoffer via Digitalmars-d-announce
      • Re: iopipe alpha ... Martin Nowak via Digitalmars-d-announce
        • Re: iopipe al... Steven Schveighoffer via Digitalmars-d-announce
          • Re: iopip... Martin Nowak via Digitalmars-d-announce
            • Re: ... Steven Schveighoffer via Digitalmars-d-announce
              • ... Martin Nowak via Digitalmars-d-announce
              • ... Steven Schveighoffer via Digitalmars-d-announce
              • ... Martin Nowak via Digitalmars-d-announce
              • ... Dmitry Olshansky via Digitalmars-d-announce

Reply via email to