Re: Preserving object props on sockets

--===============5565565006240503927==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

() Mike Gran <[email protected]>
() Sun, 24 Mar 2013 07:51:05 -0700

   I'm having a bit of a problem trying to use object properties on
   sockets.  They don't seem to be preserved between calls to
   `handle-request'.

   Old-school serveez had a svz:sock:data function for this purpose,
   which is deprecated now.

Have you tried =E2=80=98svz:sock:data=E2=80=99, then or now?  It seems ther=
e is some
confusion between the libserveez (internal) use of socket.data and the
guile-server-specific (advertized) use, judging from the discrepency
between the socket.h comments and the guile-server.c implementation.
Just calling that proc results in a segfault, here.  Looks like a case
of design incoherency.  (Drat, i KNEW i should have tested this, even as
i was writing the "Do not use" comment in the docstring...)

   Attached is a script that adds an object prop to a socket.  It
   intends to count the number of times that the socket has been used.
   But, the property vanishes with each call of `handle-request'

OK, confirmed w/ commit 832338c26, and the wip test/t008 on new repo
branch =E2=80=98q-udp-userdata=E2=80=99.

   Any suggestions?

The good news is that you found a bug and that its resolution lies
outside of libserveez proper.

The bad news is that there is no workaround in the current release (such
as using =E2=80=98svz:sock:data=E2=80=99), as far as i can tell.  I think t=
he fix
involves replacing the "SMOB creation at call time" way w/ caching and
guardians such that =E2=80=98(object-address sock)=E2=80=99 returns the sam=
e value for
=E2=80=98sock=E2=80=99 on each callback.  Whether or not to make this way (=
as opposed to
the current purely lazy way) user configurable is another question...

The ugly news is that there are more bugs (see t008) so the lightning
release i was planning is not going to happen quite like that.  You can
monitor =E2=80=98q-udp-userdata=E2=80=99 (NB: may undergo rebase) in the me=
antime.

=2D-=20
Thien-Thi Nguyen
GPG key: 4C807502

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlFQV6IACgkQZwMiJEyAdQKdvwCgxoVqHbckBjKRcNMRqOYgAVWb
QMUAoJ/jTtDLTdr+8ysQdQSWm+HkWfKG
=7hnj
-----END PGP SIGNATURE-----
--=-=-=--


--===============5565565006240503927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bug-serveez mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-serveez

--===============5565565006240503927==--