贴一首许常德的歌词《西风的话》

高中时很喜欢的一首歌，很大程度上是由于许常德老师的词的缘故。

去年秋天 无人海边 你们相恋
今年秋天 转眼之间 他已不在身边
人世间 多少梦 多少愁
秋不浓 谁把树叶都染红

The ULE issue

Now I got (partially) the point:

• A newly fork’ed thread grabs Giant
• Subsequently, the mutex procedure will call turnstile_wait
• However, the td->td_sched->ke_runq is NULL (means that some part of the new thread is not initialized completely)
• So boom! panic.

Interestingly this does not happen in !PREEMPTION case.

Now my question are:

1. who forks?
2. is it the child? the parent?
3. why the initialization is not completed with a wrong result?

感觉非常的累

不是身体上的，而是精神上的。

今天一个哥们非常愤怒地抱怨我没有做某件事，我的错。

多少也明白了当时为什么对某件事死死抓住不放，因为我实在是一个说两句话就能吓跑一半人的家伙，沟通能力太差。

决定抛弃某段代码

今天偶然发现以前做的一套CMS里面的显示发布日期的功能被干掉了。

这已经不是第一、第二或者第三次在我毫不知情的情况下作的commit了。而且我注意到commit log里面还赫然写着"Approved by: delphij"。

postfix experimental snapshot supports DSN!

Yes, finally postfix is supporting DSN. To quote Witese, this is the first postfix snapshot which provides “full support for RFC 3461..3464 Delivery Status Notifications”!

Still ULE+PREEMPTION

I have done several experiments/asserts to ensure that the panic is related to ULE+PREEMPTION case only.

ULE: no panic
4BSD: no panic
4BSD+PREEMPTION: no panic

My latest progress is that I found that sched_switch in ULE for the threaded case, can decide whether subsequent call would panic. Investigating.

Working on ULE

My company has offered me some test equipment (namely, a HP 360 with ILO, which is *great* for debugging at home!), and I has started to trip over the ULE code and find for bugs.

keys of (j),(z), etc. in FreeBSD scheduler related stuff's comments

You can obtain latest list from sys/sys/proc.h:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

 * Below is a key of locks used to protect each member of struct proc.  The
 * lock is indicated by a reference to a specific character in parens in the
 * associated comment.
 *      * - not yet protected
 *      a - only touched by curproc or parent during fork/wait
 *      b - created at fork, never changes
 *              (exception aiods switch vmspaces, but they are also
 *              marked 'P_SYSTEM' so hopefully it will be left alone)
 *      c - locked by proc mtx
 *      d - locked by allproc_lock lock
 *      e - locked by proctree_lock lock
 *      f - session mtx
 *      g - process group mtx       
 *      h - callout_lock mtx
 *      i - by curproc or the master session mtx
 *      j - locked by sched_lock mtx
 *      k - only accessed by curthread
 *      l - the attaching proc or attaching proc parent
 *      m - Giant
 *      n - not locked, lazy
 *      o - ktrace lock
 *      p - select lock (sellock)
 *      q - td_contested lock
 *      r - p_peers lock
 *      x - created at fork, only changes during single threading in exec
 *      z - zombie threads/ksegroup lock

cvs skill to minimize lock period

Today Giorgos Keramidas (keramida@) has noted that the following skill that can minimize lock period:

1. save the commit message to a file (say ~/commitlog)
2. cvs ci -F ~/commitlog file[…]

比碟仙更可怕的拍鬼游戏zz

From: http://y.sina.com.cn 2005年06月17日 11:24 榕树下 文/流浪猫

这是我的一个同事给我讲的他上高中时一个真实的故事。

那一年他上高二，因为他家住在外地，所以他从上高中就在学校住校。他们高中大部分都是长春本市的学生，住校的同学相对较少，他们寝室也就只住了四个人。从生日排行，他排老四。他们寝的老大跟他是同乡，他们俩的关系比较好。

那是快要放暑假的时候，他们考完试，等着发表成绩。这时候已经没有什么课了，学习也比较轻松。那天是星期五，晚上吃完饭没有什么事，几个人就在寝室里侃大山。说着说着，就说到一些奇异的事情上面来了。

老三就说：「哎，你们听没听过一个游戏，说是比‘碟仙’更吓人。」

老二问：「啥游戏啊？」

「拍鬼。你们听过吗？」

我们同事就说：「没听过。咋玩呀？」

• ← 上一页
• 下一页 →