Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Freebsd 20190619 #27

Closed
wants to merge 5 commits into from
Closed

Freebsd 20190619 #27

wants to merge 5 commits into from

Conversation

lyrra
Copy link

@lyrra lyrra commented Jun 20, 2019

Implementation for freebsd12.

larry added 5 commits June 19, 2019 23:26
+ autoconf checks presence of kqueue (freebsd)
  and uses that interface instead of epoll.
  Effectively choosing kqueue.c file instead of epoll.c
  Both C files shares alot of overall structure,
  but it seems easier to have them separated
  (prioritize development over maintainability for now).

+ m4-local directory holding m4 macros
  Try to anticipate a future which holds
  alot of m4 macros.
  Currently kqueue.m4 is placed there which tries
  to detect kqueue(2) freebsd interface.

+ An "extfilename" variable name is setup in
  Makefile.am that is then feed to
  fibers/config.scm.in. This determines
  what compiled library/extension to load
  (epoll.so or kqueue.so).
kqueue implementation, which emulate an epoll
interface towards guile.
+ setup a template scheme file, just like
  fibers/config.scm.in, but select what
  template to use depending on the
  operating-system.

+ No support for affinity on freebsd for now, stub it up.
The clock_id argument to clock_nanosleep differs
between linux and freebsd.

Unfortunately on freebsd, we must use
CLOCK_MONOTONIC instead of threads-clockid,
which linux uses. Probably no performance
difference, but it splits the code.
Some quick notes scribbled into fibers.texi
@aconchillo
Copy link
Collaborator

I was interested in running fibers in OS X and was going to stat working on the kqueue port. This work is great! @wingo any chance to get it merged?

@wingo
Copy link
Owner

wingo commented Nov 14, 2019

Certainly :) Aleix you are now a collaborator, feel free to merge when it looks good to you. It all looked fine to me at a first glance but since you're available to test and such, I leave the review and merge to you :)

@aconchillo
Copy link
Collaborator

@wingo sounds good. thanks! i'm taking a look at other PRs as well. i'm not yet super familiar with everything but planning to dig into it and fix the opened issues.

@aconchillo
Copy link
Collaborator

I think this should probably be closed in favor of #42.

@emixa-d
Copy link
Collaborator

emixa-d commented Sep 4, 2023

I think this should probably be closed in favor of #42.

And are you going to?

@lyrra lyrra closed this Sep 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs-changes This PR isn't quite right yet. question
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants