[gccsdk] fsync()

[Ron]

In the converting of flex and bison fork with fd to m4 business,
I used the child to write a /tmp file for the parent to open at
waitpid().
I had a report from Jeffrey that the /tmp file was still open
when the parent tried to open it.
I was thinking this was the fault of our waitpid() but I see in the
linux world the file writing job could be still unfinished even
after the write function is successful. Hence the existence of the
O_SYNC flag and the fsync() function.

Is the fsync() function going to do anything worthwhile either in the
unixlib child or the parent?

Without going into alternative waitpid signalling schemes, that could
end up with the same result. I'm thinking that a simple fix, might be to
add a sleep for the parent in the event the file isn't available.

I never had the error while testing, so I can't replicate it.
Could be because I was using scrap in RAM: and the writing was faster
or the files weren't big enough.

Ronald


___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] af_unix socketpair

[Ralph Corderoy]

Hi Lee,

> > Does sockets only exist in the current task? If I do
> > "wimp_start_task", can I use my socket in the new task?
>
> No, although the underlining OS socket is I believe system wide,
> Unixlib refers to them by file descriptor and these are allocated
> locally within each task rather than system wide as Linux might do, so
> you can't pass the file descriptors between tasks.

Unix (Linux) allocates file descriptors within a process, that's why
they all start at zero and the lowest unused one within the process is
allocated.  But I think you know that and it's terminology where we
differ.  An FD is an index into the process's FD table and that entry
references an element in the kernel's single file table, FT.

Unix can pass a file descriptor from one process to another.  What's
really being passed is the reference to the kernel's FT entry.  Thus the
FT entry may be referenced by a different FD in the receiving process,
e.g. 42 becomes 314.

> You may be able to pass the underlying OS socket between tasks, but
> Unixlib in the task you pass it to would not be aware of it; I don't
> think Unixlib can adopt an existing OS socket.

So if Unixlib wanted to grow the ability to mimic Unix in this regard,
it would be by supporting the SCM_RIGHTS ancillary message over a Unix
domain socket.  See unix(7) on Linux.

-- 
Cheers, Ralph.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK