On Sun, 05 Dec 1999 21:01:48 +0000, Duncan Simpson wrote:
cc'ed to LyX-list, because it's about LyX design:
><lots snipped>
>
>> >Depending on the blocking or shared memory properties of vfork() is guaranteed
>> >to burn you on at least one of the unicies out there.
>>
>> ? You mean older bsd clones would burn me?
>>
>In general these would *not* burn you, because they would share the memory and
>block until you called exec*(). Newer unicies might have followed the man
>page, and older Linux, and made vfork() equivilent to fork() so all that code
>that depends on the shared data and blocking does not work.
>
>> >Once you have called one
>> >of the exec*() function from a vfork()ed child you have two independent
>> >processes. The way to share things on linux is clone(2).
>>
>> Yes, but the topic was workhorse threads (light processes) to render
>> images within LyX. Here is it a real problem to write something which
>> is portable. Any idea?
>>
>Have you thought of using POSIX threads, with simulations of these were
>required? They would cover a lot of vendors at once provided you did not
>depend on the signal handling stuff (linux lacks working CLONE_PID and it
>would seriously complicate simulation on other systems). Linuxthreads is
>pthreads modulo the process ids.
Yes, I've been thinking a bit about the implemntation of X. Leroy.
There are apparently efforts to make it work on emx and win32 systems
as well, but it's hackish.
>Unless it is really expensive work the overhead and added complexity of
>multithreading is probably not worth it. The added crocks to deal with the
>multiple thread issues can be very dire (MPI is a prime examble of how not to
>do it). CSP, CCS and pi calculus are eloquent demonstrations of just how hard
>it is analyse these systems (both have ~260 page text books at CS
>undergraduate level).
I've no idea about MPI, but the complexity and portability made me come
to the same conclusion. Maybe with a fast library (like imlib) it's
worthile to implement it single process/single thread, i.e. no fork()
involved.
Greets,
Arnd
