errno issues.

[Godmar Back]

> 
> In article <199808240128.TAA19093 at sal.cs.utah.edu> you wrote:
> 
> > Instead of making errno a thread-local variable, which is what you seem
> >to be suggesting, I think it would be better to make the functions that form 
> >the syscall interface thread-safe.  I.e., instead of 
> >	int read(int, void *, size_t)
> >use
> >	int read(int, void *, size_t, size_t *actual)
> >that returns 0 on success and errno otherwise.
> 
> Yes, but this breaks all native functions that can be written too. Ie
> if someone writes a native library they have to be very carefull about
> errno. (Also, this requires all sys calls in Kaffe to be rewritten)
> 

 Stefan,

If somebody writes a native library that makes use of calls that
set errno, they'll have to go through the syscall interface anyway.
The way this is currently done is by using convenience macros defined
in jsyscall.h, which native libs must include if they want to use read(),
write(), etc.  Note that there is no other way:  we assume we link
against a C library that is oblivious to our internal threading system,
hence we must protect calls to that library and errno ourselves.

I wouldn't say the syscalls have to be completely rewritten:  we should 
be able to hide most of it in the macros for the syscalls.
For instance, read(), instead of being defined as

#define read(A,B,C)     (*Kaffe_SystemCallInterface._read)(A,B,C)

could be defined as

#define read(A,B,C)     ({ int D;
	kaffe_errno = (*Kaffe_SystemCallInterface._read)(A,B,C,&D);
	kaffe_errno == 0 ? D : -1})

where kaffe_errno is a local variable in the caller's function.
SYS_ERROR could then be defined as strerror[kaffe_errno];
I don't think any other places use errno.

This does assume that a function that invokes a function that is part
of the syscall interface immediately handles the error condition as long
as it's within scope; I think this is an okay assumption for Kaffe.

	- Godmar