But it would sort of defeat the purpose of having threads (i.e.: Running more than one thing at once)

/ Per Hedbor ()

Previous text:

2002-09-03 22:24: Subject: argv[0]?

---

can pike be made to work with gnu pth on other platforms as well? That would be pretty neat, IMHO.

/ Marek Habersack (Grendel)

That's not really true. It does matter a lot, at least where latency is concerned. Also, consider syscalls. Like, say, sendfile.

/ Per Hedbor ()

Previous text:

2002-09-04 00:16: Subject: argv[0]?

---

hmm, on an UP system it doesn't make a difference anyway.

/ Marek Habersack (Grendel)

How does pth_fork handle things like malloc?

/ Per Hedbor ()

Previous text:

2002-09-04 00:19: Subject: argv[0]?

---

you're right here. One reason that would speak for pth support, at least on Linux, would be the future ngpt library - which provides the pthreads interface, but also speaks its native one - and it has <babbling>pth_fork</babbling> which is thread-safe.

/ Marek Habersack (Grendel)

Ah. The POSIX-fork call.

This is how fork should work in POSIX. It's actually the reason for many of the problems. :-)

Consider this senario: Thread 1 locks a mutex, thread2 forks while the mutex is held, then tries to lock it. It will have to wait a while.

/ Per Hedbor ()

Previous text:

2002-09-04 00:23: Subject: argv[0]?

---

the manpage doesn't say anything specifically about malloc. Here's what's in the manual:

pid_t pth_fork(void); This is a variant of fork(2) with the difference that the current thread only is forked into a separate process, i.e., in the par- ent process nothing changes while in the child process all threads are gone except for the scheduler and the calling thread. When you really want to duplicate all threads in the current process you should use fork(2) directly. But this is usually not reason- able. Additionally this function takes care of forking handlers as established by pth_fork_push(3).

/ Marek Habersack (Grendel)