Date: Thu, 9 Jun 2011 21:23:03 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Mikolaj Golub <trociny@freebsd.org>, vadim_nuclight@mail.ru, svn-src-all@FreeBSD.org, Kostik Belousov <kib@FreeBSD.org> Subject: Re: svn commit: r222688 - head/sbin/hastd Message-ID: <20110609192303.GA2433@garage.freebsd.pl> In-Reply-To: <4DF11183.3060806@FreeBSD.org> References: <201106041601.p54G1Ut7016697@svn.freebsd.org> <BA66495E-AED3-459F-A5CD-69B91DB359BC@lists.zabbadoz.net> <4DEA653F.7070503@FreeBSD.org> <201106061057.p56Av3u7037614@kernblitz.nuclight.avtf.net> <4DED1CC5.1070001@FreeBSD.org> <86wrgvkv67.fsf@kopusha.home.net> <4DF11183.3060806@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 09, 2011 at 11:31:31AM -0700, Maxim Sobolev wrote:
> >Sorry, but I think your patch is wrong. If even it fixes the issue for y=
ou,
> >actually I think it does not fix but hides a real problem we have to add=
ress.
> >
> >Receiving the whole chunk at once should be more effectively because we =
do one
> >syscall instead of several. Also, if you receive in smaller chunks no ne=
ed to
> >set MSG_WAITALL at all.
> >
> >Besides, with your patch I am observing hangs on primary startup in
> >
> >init_remote->primary_connect->proto_connection_recv->proto_common_recv
> >
> >The primary worker process asks the parent to connect to the secondary. =
After
> >establishing the connection the parent sends connection protocol name and
> >descriptor to the worker (proto_connection_send/proto_connection_recv). =
The
> >issue here is that in proto_connection_recv() the size of protoname is
> >unknown, so it calls proto_common_recv() with size =3D 127, larger than
> >protoname ("tcp").
> >
> >It worked previously because after sending protoname proto_connection_se=
nd()
> >sends the descriptor calling sendmsg(). This is data of different type a=
nd it
> >makes recv() return although only 4 bytes of 127 requested were received.
> >
> >With your patch, after receiving these 4 bytes it returns back to recv()
> >waiting for rest 123 bytes and gets stuck forever. Don't you observe thi=
s? It
> >is strange, because for me it hangs on every start up. I am seeing this =
on
> >yesterday current.
>=20
> Yes, you are right. It appears that I did not test new code on
> primary, only on secondary. Which explains why I did not see that
> issue. Can you please try the following patch and let me know if it
> solves the issue for you?
>=20
> http://sobomax.sippysoft.com/hastd.diff
I strongly disagree with this patch. The whole proto API is now clean
and elegant. Hopefully this polution is not needed and I'd prefer to
give time to Mikolaj to investigate it. I also plan to use it in other
projects.
HAST currently doesn't support 'async' mode, so working over WAN is not
common use case for now, which makes your changes low priority. High
priority for HAST is working over LAN.
In the future it would be nice if you could send patches for review
before you commit them with 3 days MFC time. HAST is actively
maintained.
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEARECAAYFAk3xHZcACgkQForvXbEpPzSWxgCfYxY1RDBIr5uI+nxw02wIMzoz
eoUAoJaHUytquvhfrItJDxnusmCv54pX
=aSgd
-----END PGP SIGNATURE-----
--gBBFr7Ir9EOA20Yy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110609192303.GA2433>