bug-serveez
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-serveez] Preserving object props on sockets


From: Thien-Thi Nguyen
Subject: Re: [bug-serveez] Preserving object props on sockets
Date: Mon, 25 Mar 2013 14:56:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

() Mike Gran <address@hidden>
() 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 ‘svz:sock:data’, then or now?  It seems there 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 ‘q-udp-userdata’.

   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 ‘svz:sock:data’), as far as i can tell.  I think the fix
involves replacing the "SMOB creation at call time" way w/ caching and
guardians such that ‘(object-address sock)’ returns the same value for
‘sock’ 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 ‘q-udp-userdata’ (NB: may undergo rebase) in the meantime.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

Attachment: pgpthefqtOtT_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]