On Wed, Sep 21, 2016 at 3:55 AM, Holger Freyther <hol...@freyther.de> wrote:
>
> > On 20 Sep 2016, at 20:38, Mariano Martinez Peck <marianop...@gmail.com>
> wrote:
> >
> > Hi Holger,
>
>
> Good Morning,
>
> thank you for your reply.
>
>
Good morning.
> > | reader |
> > reader := OSSAttachableFileStream name:'myStream' attachTo: aFileID
> writable: false.
> > reader setNonBlocking "optional"
>
> the only issue is that i have a "int fd" and not a SQFile. In
> >>#name:attachToCFile:writable: you create a SQFile* out of a FILE*
> (OSSCFile) but judging the comment it doesn't work.
Thanks! That was the method I was trying to remember and I was failing!
hahahaha.
> The 32/64 bit issue can be solved by using FFIExternalStructure to model
> SQFile but the question if the VM was built with large file support on
> GNU/Linux is a tricky one.
>
>
Yes exactly. The basic scenario was working, but having it working in all
the different flavors of OS and VMs was tricky as the comment says. My
conclusion in this case was that it's not worth trying to do this from
image side via UFFI and that instead we should have a VM primitive.
> So maybe we create another primitive to convert a FILE* to a SQFile* (and
> have it manage the lifetime of that memory?)? And maybe another primitive
> to do the same for a Socket?
>
>
Exactly. I have been wanting this a couple of times while doing
OSSubprocess.
>
> > I still didn't understand why do you mean with a). What do you mean by
> "monitor it from being readable" ?
>
> Imagine you want to exit the image in case the file /exit changes. You
> will charge inotify to watch this filepath and if the fd becomes readable
> you already know the answer, you don't have to read the event. But true if
> I have a Socket or FileStream I can do blocking read on it as well.
>
OK, now I understand. But if you do blocking read, wouldn't be locking the
rest of the image by that read? Of course, you can do busy waiting with
none blocking reads.... but for that, inotify may be more performant?
>
>
> > I think you could dig a bit in OSSPipe, OSSAttachableFileStream and
> their usage. All classes have class comments, all methods are also
> documented, and there is quite some documentation in [1].
>
> Will look again but I didn't see anything obvious. E.g. primCreatePipe
> seems to already return two SQFile* ("fileId")?
>
>
Yes, exactly. I remember now. And as I said, I also wanted to be able to
work at fd or FILE* level and I failed.
Cheers,
--
Mariano
http://marianopeck.wordpress.com
