all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Semyonov <daniel@dsemy.com>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Richard Stallman <rms@gnu.org>,
	 iarchivedmywholelife@gmail.com, emacs-devel@gnu.org
Subject: Re: Vendoring code in a (Non?)GNU ELPA package
Date: Sat, 06 Jan 2024 12:52:12 +0200	[thread overview]
Message-ID: <871qauwx7n.fsf@dsemy.com> (raw)
In-Reply-To: <CADwFkmktaVCA4bf8HXwECarAGtUCu07wsgGGiQ0WUH62j4X21w@mail.gmail.com> (Stefan Kangas's message of "Fri, 5 Jan 2024 12:10:24 -0800")

>>>>> 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	other threads:[~2024-01-06 10:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-27  9:07 Vendoring code in a (Non?)GNU ELPA package Daniel Semyonov
2023-12-29  3:53 ` Richard Stallman
2023-12-29  4:14   ` No Wayman
2023-12-31  3:15     ` Richard Stallman
2024-01-01  3:37       ` Dmitry Gutov
2024-01-04  3:59         ` Richard Stallman
2024-01-01 12:07       ` Daniel Semyonov
2024-01-03  4:14         ` Richard Stallman
2024-01-03  6:20           ` Daniel Semyonov
2024-01-04  4:56             ` Stefan Kangas
2024-01-04 15:02               ` Daniel Semyonov
2024-01-05 20:10                 ` Stefan Kangas
2024-01-06 10:52                   ` Daniel Semyonov [this message]
2024-01-06 11:45                     ` Stefan Kangas
2024-01-06 19:04                       ` No Wayman
2024-01-08  3:46                         ` Richard Stallman
2024-01-08  4:00                           ` No Wayman
2024-01-10 12:07                   ` Stefan Kangas
2024-01-06  4:35                 ` Richard Stallman
2023-12-29  7:57   ` Daniel Semyonov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qauwx7n.fsf@dsemy.com \
    --to=daniel@dsemy.com \
    --cc=emacs-devel@gnu.org \
    --cc=iarchivedmywholelife@gmail.com \
    --cc=rms@gnu.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.