bug#18592: FFI should have portable access to ‘errno’

[Nala Ginrut]

hi Mark!
Fairly speaking, your new proposal sounds cool.
But is it necessary to do redundant rework if there's no obvious problem
in the first proposed patch?
Besides, I think the new proposal may introduce extra complexity to
implement. That's what I actually concern about.
IMHO, it is better to avoid introducing more complexities, the simple
way is better for debugging and maintaining.
And it is better for us to have such feature soon, since we need to make
more cool projects to enhance Guile usability in real world.

Anyway, you have the big picture in mind for Guile, maybe you have your
reason for that?

Best regards.


On Thu, 2016-03-03 at 12:36 -0500, Mark H Weaver wrote:
> Nala Ginrut <address@hidden> writes:
> 
> > Is there still problem? I'm fine with the patch, and I'm expecting to
> > merge it ASAP. Anyway, please don't hesitate to tell me if there's still
> > any problem, I'm glad to help to do it better. I really need it.
> 
> Sorry for the delay, but I'm having second thoughts about whether this
> is the right approach.  Perhaps we should instead make a set of
> commitments that certain basic operations like scheme evaluation, heap
> allocation, and basic scheme procedures will leave 'errno' unchanged.
> 
> At the API level, the idea would be that if you write Scheme code that
> makes a reasonable effort to avoid non-trivial operations between the
> FFI call and the call to (errno) or (set-errno! <n>), this would be
> sufficient.
> 
> At an implementation level, it would require us to save and restore
> 'errno' around C library calls that are made by Guile's runtime system
> without the user's knowledge, most notably when running GC (during
> allocation) or when running asyncs and things like that.
> 
> What do you think?
> 
>       Mark