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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
