If it executes sequentially, then I can just make function calls
instead of
creating threads isnt it? Or, is there a way that I can make it work
differently?
Sri.
It depends upon what you're doing. Nothing in the POSIX standard requires
timeslicing. The usual reason you use PTH is
Wait... I thought blocking I/O, which is default, will block the entire
process; not just the thread. In other words, I thought
If that were true, what would the difference be between 'pth_write' and
'write' or 'pth_read' and 'read'?
DS
why a thread cannot suspend itself?
What would unsuspend it?
If it's not too hard to modify the pth src, then which files should I
hack so that a thread can suspend itself? Thanks.
No need. Just block on a condition variable and have another thread that
wishes to wake the
On Thu, 11 Oct 2001 13:31:52 -0600, Armando F Ibarra wrote:
Hi, just a question:
Does the pth_yield funciton really work?, because the scheduler still
attending just one thread at once, and lets another thread to work until the
previous thread ends its work.
Your first statement, that
On 05 Jan 2002 21:42:51 -0600, Gordon Matzigkeit wrote:
This is a simple test to show that Pth and Pthreads can't run in the same
executable on my machine. Is there a good reason why this is so?
I would have thought that Pth would happily run in a single kernel thread.
Look at the
On Thu, 31 Jan 2002 15:41:31 -0800, Archie Cobbs wrote:
I've just found that if you have a thread waiting on an event
ring, and another thread manipulates that ring, what you might
hope to happen (the waiting thread picks up the new events) doesn't
seem to happen.
First, can anyone confirm or
On Mon, 29 Jul 2002 13:44:48 -0700, Jason Evans wrote:
I've been subscribed to this list for several weeks now, and have seen no
indication that someone is actually maintaining pth. There have been at
least 4 bug reports, 3 of which included fixes. I'd like to know if
someone is keeping track
If the context-switching overhead turns out to be too high, then I will do
exactly that. But it will mean maintaining state for each connection, and
that state will only grow more complex with future enhancements by myself
and others.
Umm, huh?! If you don't maintain state for each
Ah, well, I meant that a state machine must store state
explicitly, whereas
with threaded code the state is implied in the code flow (in effect, the
thread system itself is a state machine.) If each thread
executes a simple
function like void foo() {A; B; C;}, then the equivalent state
The costs depend on the particular method Pth uses for the context
implementation, of course. But all available methods Pth uses are very
cheap, because they are user-space only methods. Keep also in mind that
because Pth is a non-preemtive threading implementation, the context
Wouldn't it be a waste of resource of you were to create same number of
Threads as the Timers required.
Yes, it would.
Instead if we had a functionality
within pth
available that would be the best approach or use the underlying Target OS
Timer functionality to get the same
I have some doubts regarding the way in which the Pth scheduler
implements Priority based non-preemptive Scheduling.
When a low-priority thread make a higher-priority thread ready-to-run, it
is offering the CPU to that higher-priority thread.
My program is using the pth cond and
My program is using the pth cond and mutex
variables for synchronization between the threads.
From a low priority thread, I am calling
pth_cond_notify() and immediately a higher priority
thread (which was there in the ready queue) was getting scheduled.
Well, that's the purpose
13 matches
Mail list logo
