>
> That's my interpretation. So basically pth_read() and pth_write() work
> the same as read() and write() - exactly what you'd expect. Trust me,
Maybe I'm the only one who expected they're non-blocking by default.
Thank you very much for pointing out my erroneous interpretation.
BTW, I have two questions here.
1.
Why "suspending the current thread is not allowed"? ps version p.10 of
pth(1) manual. int pth_suspend(pth_t tid). I mean, is it too difficult
to do so? Because of this, I created a thread which performs pth_suspend
for the caller.
2.
I'm having a trouble with message passing.
Aforementioned pth_suspend thread uses busy loop to get the tid in the
initial implementation, which wastes cpu but worked fine. Then I changed
it to message passing. It's not working for now, so I cannot really confirm
but, when pth_wait(ev) where ev = pth_event(PTH_EVENT_MSG, mp) where mp is
a message port is waiting for the message to arrive, is pth scheduler use
busy loop or polling? If so, msg passing is useless in this case. Why I'd
like to do this is because I'd like to pre-spawn multiple threads as a
handler; this is a similar strategy as apache does. i.e. create pool of
processes when it starts, then as a request arrived, the main assigns that
request to the pre-forked processes saving the process creation overhead.
I'm trying to do it at thread level. Anyhow, during the dubbuging, I wrote
a small test code, which is meaningless, but here it is:
(gdb) run
Starting program: /mnt/sda1/ish/cow/tes.tid/msg/ma
pth_init: enter
pth_spawn: enter
pth_mctx_set: enter
Program received signal SIGUSR1, User defined signal 1.
0x4004edcb in __sigsuspend (set=0xbffff87c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
48 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
(gdb) bt
#0 0x4004edcb in __sigsuspend (set=0xbffff87c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1 0x804ce06 in __pth_mctx_set (mctx=0x8053bac, func=0xfffffffc,
sk_addr_lo=0x8053d10 "Þ", sk_addr_hi=0x8063d10 "") at pth_mctx.c:307
#2 0x804918a in pth_spawn (attr=0xbffffad0, func=0x804d2a4 <__pth_scheduler>,
arg=0xfffffffc) at pth_lib.c:267
#3 0x8048cce in pth_init () at pth_lib.c:71
#4 0x8048bbb in main () at ma.c:12
and the source code is:
int main ()
{
pth_t newt;
pth_msgport_t mp;
pth_attr_t attrx;
int x;
if(!pth_init())
{
perror("pth_init");
exit(1);
}
/*
attrx = pth_attr_new();
pth_attr_set(attrx, PTH_ATTR_NAME, "hand");
pth_attr_set(attrx, PTH_ATTR_JOINABLE, TRUE);
pth_attr_set(attrx, PTH_ATTR_STACK_SIZE, 16*1024);
*/
fprintf(stderr, "so what do you want?\n");
return 0;
}
---
Please note that I removed handle function and commented out pth_spawn.
Initially I got the same error at pth_spawn, so I thought it caused the problem.
but after commenting it out, I still get the same result.
It runs perfectly fine by itself, but it fails to run on GDB.
libpth was compiled with debug enabled, and all test suits passed.
Any suggestion? TIA.
--
Takashi Ishihara http://wwwcsif.cs.ucdavis.edu/~ishihara
;; The first precept was never to accept a thing as true until I knew it
;; as such without a single doubt. (Rene Descartes, 1637)
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
