emacs-devel
[Top][All Lists]
Advanced

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

Re: Vendoring code in a (Non?)GNU ELPA package


From: Daniel Semyonov
Subject: Re: Vendoring code in a (Non?)GNU ELPA package
Date: Sat, 06 Jan 2024 12:52:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

>>>>> Stefan Kangas writes:

    > Daniel Semyonov <daniel@dsemy.com> writes:
    >> I don't see why it wouldn't be possible, though it would change
    >> the behavior of `play-sound' slightly, so maybe a new function
    >> should be introduced instead.
    >> 
    >> I could try to implement an `async-play-sound-internal' built-in
    >> function (for GNU/Linux only at first), using the available
    >> subroutines in "src/sound.c", though it might take me a while as
    >> I have near zero experience with Emacs' C code, and this will be
    >> lower level than the implementation in my module.

    > We could also change the signature from

    >     (play-sound SOUND)

    > to

    >     (play-sound SOUND &optional ASYNC)

    > or something along those lines.  Though, on the face of things, I
    > don't think I understand why `play-sound` should block.  Is there
    > a good reason for that, or is it just an implementation accident?
    > And are there any important reasons to preserve its blocking
    > behavior?

No clue honestly, I've never seen code that uses `play-audio'.
It isn't surprising though, `play-audio' in it's current state isn't
very useful apart from playing very short sounds IMO.

    >> BTW, is using threads (pthreads) acceptable?  I saw many files
    >> under "src/" that include "pthread.h" but I couldn't find any
    >> file where a thread is created (though maybe I missed something).
    >> If not, I'm not really sure how to implement this (I only ever
    >> did async programming in C using pthreads, and since I don't have
    >> any sort of formal background in C, I never learned or tried any
    >> other method).

    > Threads sound like an unnecessary complication, and I'm not sure
    > why we would need them.  Aren't there non-blocking calls that we
    > could use?

There are, but I had trouble understanding how they could actually be
used in this situation.  In any case I did some more research and I
think I understand how to implement this without threads now (at least
for ALSA).

    > Or would that require pulling in pulseaudio?

No need.

    > BTW, if this new feature only works on GNU/Linux at first, then
    > that is fine according to our guidelines.

Great.



reply via email to

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