In order to implement thread-blocking I/O I have to write my own wrapper
services and I'm not sure what is the best way to proceed.
I've been doing some experimenting and here's what I've come up with:
In pthread_io.c I have the following declaration:
static inline
_syscall2(long,socketcall,int,call,unsigned long *, args );
Followed by a bunch of functions of which the following, syscall_accept(), is a
typical example:
static int
syscall_accept( int fd, struct sockaddr *addr, int *addrlen )
{
int ret;
unsigned long args[3];
/*
* Init the args and call the kernel.
*/
args[0] = (unsigned long) fd;
args[1] = (unsigned long) addr;
args[2] = (unsigned long) addrlen;
pthread_mutex_lock( &syscall_lock );
ret = socketcall( SYS_ACCEPT, args );
pthread_mutex_unlock( &syscall_lock );
/*
* If the call failed because of a signal, then continue to retry until
* we succeed or fail for some other reason. NB: Later on we'll
* integrate this in with the per-thread signal facility and do this
* correctly. For now, just restart it.
*/
while( ret < OK )
{
if( ret != -EINTR )
{
SET_ERRNO(ret);
break;
}
pthread_mutex_lock( &syscall_lock );
ret = socketcall( SYS_ACCEPT, args );
pthread_mutex_unlock( &syscall_lock );
}
return( ret );
}
What I found was that when I try to link a test program with this module
(containing these wrapper functions), linker can not find the socketcall() entry
point unless I include the _syscall2(...) declaration!
First, can someone explain to me what's going on? Is this _syscall2() some kind
of magic macro? I happened upon this strategy by browsing thru the ./sysdeps
directory in the libgcc library sources and this is almost exactly what is
done there, albeit I don't understand why.
Second, do I really need to serialize the process's calls to system services?
Off the top of my head, I don't see why this is necessary, but I've got the
locks in place just in case someone tells me that Linux's kernel is
partially preemptible.
Finally, the global lock notwithstanding, is this really the best way to write
wrappers that call system services? Any advice, suggestions, pointers would be
very welcome
Regards,
/mtp
+-----------------------------------------------------------------------+
| Michael T. Peterson | The hell you say. My opinions are my own |
| http://www.aa.net/~mtp/ | and worth every damn cent you paid. |
+-----------------------------------------------------------------------+