Threads on SCO OpenServer 3.2 5.0.5
Christian
I can't find any support of threads under SCO 5.0.5. Aren't they available
on this sytem ?
Christian
Brian K. White
"Christian" <cgreg...@yahoo.com> wrote in message
news:3c8dc9ff$0$24014$4d4e...@read.news.fr.uu.net...
No kernel threads.
Someone more authoritative will have to, and surely will, comment on this,
but from what I understand there cannot be any, at least not in practical
terms. It is simply sysv r4 and above territory (aka: unixware &
open-unix), while OpenServer/OpenDesktop/SCO-Unix are all sysv r3. hence
the full actual name of "SCO 5.0.5" which is really (assuming you have
5.0.5 with tcp/ip):
"SCO Open Server Enterprise r3.2v5.0.5"
The key part here being "r3.2"
There are a few different user-space implementations in the form of
threads libraries.
ftp://ftp2.caldera.com/pub/skunkware/osr5
lipraries/pthreads # seems to be the most used
libraries/pth # seems to be more recent
also I think one or the other or something else entirely may be included
within
libraries/glib
and/or
libraries/Glib
They have been used with some success to build various of the other things
you see under skunkware/osr5 so they can be used to port existing code,
but I don't know what the real world performance benefits are to using
them in the case of writing new code for Open Server and deciding you want
to make the app threaded.
I know they basically spawn whole new full processes, which might mean
that they would automatically take advantage of multiple CPU's if you had
more than one cpu and the sco SMP software and license installed.
Can anyone comment on that?
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Christian
news:%Lnj8.56483$hO6.4...@bin4.nnrp.aus1.giganews.com...
Thanks for the reply Brian.
In the meantime, i had a look at GNU Pthreads. It might be a solution
eventhough i can't figure out how come that would allow the program to
handle threads if the kernel itself doesn't support them. By 'they basically
spawn whole new full processes' do you mean that with this lib, threads are
actually processes ?
Brian K. White
> Thanks for the reply Brian.
>
> In the meantime, i had a look at GNU Pthreads. It might be a solution
> eventhough i can't figure out how come that would allow the program to
> handle threads if the kernel itself doesn't support them. By 'they
basically
> spawn whole new full processes' do you mean that with this lib, threads
are
> actually processes ?
and the answer is... "I think so"
a couple years ago I was looking at the various threads libraries because
it was a hobby of mine to build gnu apps for open server, and ghostscript
6 had become threaded, and I did get it to build using... I forget which
library now, because someone else also built it and packaged it in
skunkware so I've just been using that since then.
While I was doing that, I seem to recall that was how these libraries
worked, but today I cannot say and don't feel like looking right now, so
take it as a hint or clue as to what may be going on to keep in mind while
you look yourself.
J. L. Schilling
>
> In the meantime, i had a look at GNU Pthreads. It might be a solution
> eventhough i can't figure out how come that would allow the program to
> handle threads if the kernel itself doesn't support them.
Libraries such as GNU Pthreads are basically "user space" threads libraries
when run on OpenServer.
All of the threads exist within one user process and one kernel process.
The threads each have their own stack and their own state, with something
like getcontext()/setcontext() being used to do context switches amongst
the threads. As a result, such a library can support threading even
though the kernel doesn't have any concept of threads or light-weight
processes.
The downside is that you get no benefit from being on a multiprocessor
machine, and implementing non-blocking/asynchronous I/O is more
problematic. See
http://www.gnu.org/software/pth/pth-manual.html#the world of threading
for more.
Jonathan Schilling
Frank
We're working on a SCO OpenServer 5.0.5 and are trying to port an
application from a Mandrake Linux v.7.2.2.2.17.21.mdk (kernel version).
We seem to have different thread behaviour on these two platforms. Can
anyone tell the main differences between the threads programming and
behaviour
on both platforms?
It seems this thread has some relation to our problem.
Basically I need to know are we in trouble (1 week to deadline for this
port)?
Any pointers, help, suggestions are appriciated!
Thanks,
Frank
J. L. Schilling <jlsels...@my-deja.com> wrote in message
news:ff3c0649.0203...@posting.google.com...
J. L. Schilling
>
> We're working on a SCO OpenServer 5.0.5 and are trying to port an
> application from a Mandrake Linux v.7.2.2.2.17.21.mdk (kernel version).
> We seem to have different thread behaviour on these two platforms. Can
> anyone tell the main differences between the threads programming and
> behaviour on both platforms?
One OS supports threads and one doesn't, that's a pretty big difference!
On Linux each application thread will be a separate cloned process,
managed by Linux's threads library. You don't say what third-party
threads package you are using on OpenServer, but as stated previously
it will be trying to manage threading within one user-space process.
There's bound to be a lot of difference between these two models,
in terms of performance, preemption, reliability, scalability, etc.
> Basically I need to know are we in trouble (1 week to deadline for this
> port)?
Time to start ordering in the pizza and Cokes!
Jonathan Schilling