--qOEfHYdX8LquYLAx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

yamt:
>=20
> >because a caller doesn't know for what so_send will use the proc pointer
> >as Matthias pointed, it can't decide which proc pointer to pass.
> >i called it as 'a random proc pointer'.
> >(probably 'a pointer to a random proc' is more clear.)

My paraphrasing of this question goes like this:

"I am a caller of the so_send (and similar) API, which wants a proc *.
What proc * should I pass? I don't happen to have an obvious choice
for a proc * to give it that makes sense in my context.  I don't want
to use curproc as a cop-out, because I'm trying to help that die, and
for all I know it's as bad a choice as any other ad-hoc proc *
anyway."

What would help me make the decision:
 - what it needs from the proc * and how it is used
 - whether it can be NULL and under what circumstances
 - making it use something more direct and purpose-specific than
   indirection through a proc *, which I might have (your list)

So, I think you are agreeing at cross purposes :)

--
Dan.
--qOEfHYdX8LquYLAx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFAstnIEAVxvV4N66cRAv6UAJ0aycOPtCNdURzFQoFj/t8Z39jjUgCgyLI1
99H89ZxdPEVeA9EEdynwOl0=
=p8ZS
-----END PGP SIGNATURE-----

--qOEfHYdX8LquYLAx--