Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Dec 2002 18:21:08 +0800
From:      "ouyang kai" <oykai@msn.com>
To:        julian@elischer.org
Cc:        hackers@FreeBSD.org
Subject:   Re: Some problems about KSE
Message-ID:  <F20Rqf69aZbLAX3cf3e00010b50@hotmail.com>

next in thread | raw e-mail | index | archive | help
>From: Julian Elischer <julian@elischer.org>
>Well it's still being written so you may be a bit ahead of yourself..
>cc ... -lkse ....
>no use -lkse until we have if more finished... then it will become
>-lpthread
>the fix was committed yesterday.
>the UTS fills in km_func before creating the KSE and loaded by the
>kernel. At THIS time it is never looked at again, but that could change
>in the future.
  I have cvsup my box today, the 'ksetest' works nice. But only one time, 
when I am excuting the 'ksetest'on ptty0, I am excuting 'tar zcvf 
src1212.tgz ./src' on ptty1. The box crash. I do not know why. I want to 
repeat the problem, but the box works well. so, I think it may be irrelevant 
with KSE.
  I have studied the 'ksetest' code, if the app programmers use KSE as your 
method, I think it is too hard.:)
  In the furture, whether do the app programmers never use the round robin 
KSE functions(kse_create, kse_release, etc.) directly? Only the pthread 
lib(UTS) considers calling KSE functions?
>(see how ksetest is written)
I do not know whether my understanding about 'ksetest' is right, please 
point out.
in 'ksetest' program:
   you simulated the UTS mechanism. In this mechanism:
   1. one KSEG is a queue(runq_init);
   2. every thread(in userland) is managed by the uts_data 
structure(init_uts);
   3. through thread_start, you start a child thread, the child thread 
function is 'aaaa'.
   4. through start_uts, you setup a bridge between UTS and KT(kse_create).

I wants to draw my understanding about this 'ksetest', but I can not finish 
it.:(
User Program   (kse_thr_mailbox) UTS     (kse_mailbox)   KT
ksetest
                queue1                           KSEG1
  child1                        data1    (have a bridge)
  child2
                                data2    (have a bridge)
                queue2                           KSEG2
  child3                        data3    (have a bridge)
  child4
  child5
                                data4    (have a bridge with KSEG1 ???)
In the main() function, I have some puzzles:
  why do you start child thread with 'data1' two times and with 'data3' 
three times? I think the 'uts_data' should the the management structure in 
UTS, why use the same 'uts_data' instances manage one queue? why could not 
use 'data2' or 'data4' to create child thread?
  why did you call "start_uts(&data4, 0);" by "thread_start", what is your 
purpose? Why the 'data4' is in queue2 but belongs to KSEG1? So, I am puzzled 
about the relationship between queue and KSEG.
  Maybe, from beginning, I am wrong? :(
>
>It is indetirminate because that code has not been written.
>At this time the signal will be delivered in the normal way
>to the next thread to enter the kernel in any way.
>This actually works for a surprising number of programs as long as they
>do not need to do any
>thread_specific actions in the handler.
>How to route the signals to a specific thread is still under discussion.
Oh, later...


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F20Rqf69aZbLAX3cf3e00010b50>