search

JeffGarland / liaw2019-process

Repository for initial drafting of boost.process standards paper
MIT License
5 stars 4 forks source link

LEWGI Cologne: Are named pipes a version 1 feature? #35

Open JeffGarland opened 4 years ago

JeffGarland commented 4 years ago

Unfortunately I'm not sure now if the question was 'are pipes needed' in V1. Basically there's nothing else on Windows so the use of named pipes is more for consistency than anything else if I'm not mistaken.

eliaskosunen commented 4 years ago

I think the question was whether pipes should be a part of this paper or be proposed separately.

If pipes are here to say, I’d say we’d need to keep named pipes as well.

JeffGarland commented 4 years ago

The SG1 support for making pipes into a different proposal was tepid at best (not seeing the poll numbers just now, but that's my recollection). If we did that I guess we'd be left with the pipe_stream and pipe_buf for the api?

JeffGarland commented 4 years ago

Actually @klemens-morgenstern describes a potential path in the roadmap issue #30 -- basically leaving the streams and pulling the pipes into another paper. Same with the environment. Pipes would never need to come back since they become an implementation detail -- environment we will have to have...

That's probably what we should do to make things more tractable for LEWGI for now.

klemens-morgenstern commented 4 years ago

The only way to have an async pipe is through a named pipe on windows. So it comes with the async stuff and I would prefer not to split pipe functionality up. I also think that async is very, very important, synchronous I/O - especially with pipes - is a source of way too many deadlocks.

JeffGarland commented 4 years ago

Agree -- thx for confirming that. But...if we take the pipes out in version 1 if I'm not mistaken all the async goes away bc we're back users only having pipe_stream and pipe_stream_buf as interfaces -- and all the async and pipe becomes implementation detail. Is that not what you were suggesting in #30?

klemens-morgenstern commented 4 years ago

I would move pipe_stream and pipe_stream_buf to the other paper as well.

JeffGarland commented 4 years ago

Unfortunately that doesn't really eliminate anything -- it just moves it to another paper which is required for process to move forward. I'd rather hold firm with one unified proposal for the moment and take the flack for not cutting enough. I pretty much agree with the sub-group of SG1 that making more papers doesn't make the job simpler ultimately.

eliaskosunen commented 4 years ago

In Belfast, LEWGI encouraged the removal of named pipes. The primary concern was about security; doing mutual authentication would be slow and painful.

JeffGarland commented 4 years ago

As Klemens points out on Windows it will basically be a named pipe cause that's how they all are. So really the issue we have is with the constructor for a named pipe -- which I believe we can basically remove for the core functionality since it can be a randomly generated name internal pipes. At least that's what we should see if it will work.

klemens-morgenstern commented 4 years ago

Security doesn't need to be a concern,they behave basically like files, or at least we can specify it that way.

The nice thing is that I can use them for IO with a process that thinks it's a file. At least to a degree.