Hi Dave, On 11 May 2018 at 03:58, David T. Lewis <[email protected]> wrote: > On Wed, May 09, 2018 at 01:41:47PM +0200, Thierry Goubier wrote: >> 2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <[email protected]>: >> > You mean you made a subclass of StandardFilestream yourself ? >> >> There are a few subclasses of StandardFileStream in OSProcess: >> AttachableFileStream, AsyncFileReadStream and >> BufferedAsyncFileReadStream. They will need to be ported. >> >> > If yes, can you describe briefly why you did so ? >> >> As far as my analysis go, AttachableFileStream refers to and >> manipulates the underlying ioHandle of a unix pipe stream, >> AsyncFileReadStream interacts with the asynchronous io extensions of >> the vm to observe that io handle, and a BufferedAsyncFileReadStream >> add a thread-safe, buffered, blocking API for smalltalk processe on >> top. > > That's right. > > I'm sorry I have not been keeping up with this discussion, but one thought > that comes to mind - the AttachableFileStream hierarchy is something that > would better be replaced by some kind of delegation. It was a hack that I > did a long time ago to allow OSProcess to work without modifying the base > image. But since then, we have added multibyte characters and streams, and > we have different file and stream models in Squeak/Pharo/Cuis (Cuis is an > important target platform from my POV). > > I don't have a solution in mind, my sense is that if we find a way to make > AttachableFileStream go away, then that solution would very likely make > it unnecessary to develop and maintain separate Squeak/Pharo/Cuis forks > moving forward. > > Note that the only fundamental thing that AttachableFileStream does is this: > > AttachableFileStream class>>name: aSymbolOrString attachTo: anIOHandle > writable: readWriteFlag > "Create a new instance attached to anIOHandle, where anIOHandle > represents an open IO channel. For write streams, this represents two > Smalltalk streams which write to the same OS file or output stream, > presumably with interleaved output. The purpose of this method is to > permit a FileStream to be attached to an existing IOHandle, such as > the IOHandle for standard input, standard output, and standard error." > > ^ (super basicNew > name: aSymbolOrString > attachTo: anIOHandle > writable: readWriteFlag) initialize > > > The method comment refers to "IOHandle" which was another old project I was > doing, but IOHandle basically means the #fileID field of a file stream. > > If it was just AttachableFileStream that needed to be refactored out of > existence, > it would be easy. But I later added quite a bit a behavior to > BufferedAsyncFileReadStream > and I'm not sure what might be needed to make this work properly. > > Sven, I suspect that you are the most knowledgeable in this area, so any > suggestions would be welcome.
Are the two primitives that were added to the VM a couple of months ago (primitiveConnectToFileDescriptor & primitiveConnectToFile) enough to allow AttachableFileStream to be removed? Also, borrowing primitiveSQFileSetNonBlocking from OSProcess I was able to open a named pipe and read from it in a non-blocking way using the standard Pharo 7 file stream (BinaryFileStream). I'd like to look at getting AsyncFile working with it, but that's a long way down the ToDo list. HTH, Alistair
