Subject: Re: [linux-audio-dev] Article about multithreading
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 18 2001 - 23:24:22 EEST
>Were it in this thread we asked about easy-to-use library for handling
>multithreading and the like?
>
>We could compile such library if people are interested. Guenter has already
>something. I have routines to fork a new process and have a FD between them;
>the routines could be extended to handle a shared memory system. I have
>also shmalloc() and mmapalloc(). Yet I have an FD server.
>
>It may not sound like one needs to have utility routines for fork()
>and pipe() but I needed the system to be clear enough. I still need
>more utilities for setting things running almost transparently.
Juhana, you're not talking about multithreading as its normally
understood. You're talking about inter-process communication and
synchronization. Multithreading means doing things in the same address
space, which under Linux typically means that the file table is also
shared.
>OK, I can dig my code and put them available. It is better than nothing.
Wrong question: is it better than pthreads? And how reliably does it
work? There are real problems, for example, in ensuring that two
processes can shmat() a shared memory segment at the same point in
their address space. If they fail, then pointers valid in one process
(read: address space) are not valid in the other, and all references
to locations in shared memory must look like the old x86 segmented
model (segment:offset). Yuck.
Of course, if one process forks the other, this problem doesn't apply
to existing shared memory segments, but thats only a small subset of
the set of problems and applications that such techniques can be used
(and be useful) for.
--p
This archive was generated by hypermail 2b28 : Mon Jun 18 2001 - 23:24:02 EEST