Hi Alistair, On Fri, May 11, 2018 at 03:09:20PM +0200, Alistair Grant wrote:
Hi Dave,
On 11 May 2018 at 03:58, David T. Lewis <lewis@mail.msen.com> 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 <sven@stfx.eu>:
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?
No, I was referring only to the actual file stream hierarchy. Long ago, I tapped into StandardFileStream with some subclasses that do useful things for OSProcess. That is clearly a hack, and I'm sure we could do better. Having said that, I have not looked at Pharo 7 yet so maybe I don't know what I'm talking about ;-)
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.
Good, primitiveSQFileSetNonBlocking certainly should work for that, and I'm glad to hear that it does. Dave
HTH, Alistair