labath wrote: > > * do we need regular file support > > We don't strictly need this for anything I am aware of, I can remove it for > now. A 'better' solution would be to stat the file and then watch the > directory for changes and re-stat the file. Thats used in libuv (nodejs). I > think libdispatch on Windows doesn't actually do anything for files, so you > don't get notified if a file on disk changes.
Yeah, let's remove that. I think that "watching for file/directory" changes is a completely different feature.. > > > * do we need the pipe _thread_ > > In order to support both anonymous pipes, like stdin, and named pipes we > would need the thread. > > We could specialize this further and have the thread only for anonymous pipes > and use a different strategy for named pipes, but the current solution works > for both. I see. I take it that's because anonymous pipes are created without FILE_FLAG_OVERLAPPED. Btw, my understanding is that an anonymous pipe is just a named pipe with a funny name (at least until windows 10, or something) and some with some hardcoded flags (like the absence of overlapped I/O). This is why lldb creates "anonymous pipes" as named -- so it can enable overlapped I/O. So for internal pipe uses, I think we're safe. It gets trickier for pipes that get passed from the outside, but I wouldn't be surprised if VSCode did something similar -- it's likely it also wants to do some overlapped I/O. Could you check if that is the case? I'm not sure what that would mean for the implementation (I like the generality, but I also hate the idea of creating a thread for every pipe object), but I think it'd be good to have know this. https://github.com/llvm/llvm-project/pull/145621 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
