At Wed, 16 Sep 2015 17:16:50 +0800, WarGrey Gyoudmon Ju wrote:
> foxpipe.c is a wrapper of libssh2 APIs that suitable to work with (sync)
> and custodian. Everything is okay except that the sigfault annoys me a lot.
>
> typedef struct foxpipe_session {
>
> LIBSSH2_SESSION *sshclient;
>
> Scheme_Input_Port *dev_tcpin;
>
> Scheme_Output_Port *dev_tcpout;
>
> intptr_t sockfd;
>
> } foxpipe_session_t;
If memory for this structure is allocated with malloc(), the Racket GC
will not be able to see the references to `dev_tcpin` and `dev_tcpout`.
It may collect or (more likely) move those objects and not update the
references.
> The above stack is the shape of almost all failures if I use
> scheme_malloc() as the allocator. [More earlier, the failure may
> occasionally occur at scheme_fd_to_semaphore running minutes or hours later
> if scheme_malloc_atomic() is used]
Neither scheme_malloc() nor scheme_malloc_atomic() will work as-is. The
former doesn't work because the record includes a non-pointer. The
latter doesn't work because the record includes pointers.
You could make everything in the record pointer with a level of
indirection: allocate atomic memory to hold `sockfd`, and then put that
pointer in the record (and so on for the other structures). Then,
scheme_malloc() can work for the main structure.
But, also, to use either of those, you need to use "xform" to adjustthe
C code for GC, or you need to adjust the C code to cooperate explicitly
with the GC using MZ_GC_DECL_REG(), etc. Are you using "xform" already?
More generally, this code looks like something that is more easily
handled by Racket and `ffi/unsafe`, instead of writing new C code. You
still have to be aware of GC issues, but not to the same degree.
> Another question, what is the order does custodian shutdown objects? Say,
> if the original tcp ports and my channel ports are both managed by the same
> custodian, what will happen? How about custodian and subcustodian?
No order is specified, but note that it's ok to "close" a port multiple
times.
(If you have in mind using the ports for communication on shutdown,
then that has bigger problems, since shutdown operations are supposed
to be non-blocking.)
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
