headers
Mark Heily | 11 Apr 2011 05:42

porting status

Here's some news on the effor to porting libdispatch to other platforms:

  * libkqueue has been submitted for inclusion in Fedora:

         https://bugzilla.redhat.com/show_bug.cgi?id=684446

  * libpthread_workqueue has been uploaded to the Debian archive:

	http://ftp-master.debian.org/new/libpthread-workqueue_0.4.1-1.html

  * All of the libdispatch unit tests are working on Linux using the latest 
SVN sources of libkqueue and libpthread_workqueue. Here's the output:

==================================================
[TEST] Dispatch (Public) API
[PID] 23983
==================================================

	Actual: 0x602540
	Expected: 0x602540
[PASS] dispatch_get_main_queue
PASS: dispatch_api

==================================================
[TEST] Dispatch C99
[PID] 24003
==================================================

	Actual: 0x602540
	Expected: 0x602540
(Continue reading)

Permalink | Reply | 6 comments |
headers
Joakim Johansson | 11 Apr 2011 11:32
Favicon

Re: porting status

Thanks Mark, working quite nicely now!

For completeness, below are the latest results from Solaris 10/x86_64 also using clang (libkqueue r469,
libpthread_workqueue r113, libdispatch r197 - current ’trunk’) - all tests succeeded.

Cheers,

Joakim

SunOS ply 5.10 Generic_144489-06 i86pc i386 i86pc

==================================================
[TEST] Dispatch (Public) API
[PID] 16510
==================================================

        Actual: 412970
        Expected: 412970
[PASS] dispatch_get_main_queue
PASS: dispatch_api

==================================================
[TEST] Dispatch C99
[PID] 16526
==================================================

        Actual: 412970
        Expected: 412970
[PASS] dispatch_get_main_queue
PASS: dispatch_c99
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jordan K. Hubbard | 11 Apr 2011 20:12
Picon
Favicon

Re: porting status


On Apr 11, 2011, at 2:32 AM, Joakim Johansson wrote:

> Thanks Mark, working quite nicely now!
> 
> For completeness, below are the latest results from Solaris 10/x86_64 also using clang (libkqueue r469,
libpthread_workqueue r113, libdispatch r197 - current ’trunk’) - all tests succeeded.

Hi guys,

Just out of curiosity, is this going to essentially be the "preferred interface" (libpthread_workqueue +
libkqueue) going forward for non-MacOSX platforms?  Don't get me wrong:  Anything which requires the
fewest contortions in libdispatch to work is great for us since it won't "cruft up" the code with lots of
#ifdefs, but at the same time if there are better ways to plumb at least the pthread_workqueue stuff such
that we can be more agile on other platforms, it would be interesting to at least *have* that architectural
discussion.  Such discussion may or may not lead anywhere, but it seems like we're starting to gain
traction on other platforms and it makes me curious as to how well we're "impedance matched" to them.  Any
comments on that?

Thanks,

- Jordan
Permalink | Reply | 4 comments |
headers
Joakim Johansson | 12 Apr 2011 18:27
Favicon

Re: porting status

Hi Jordan,

Some thoughts:

I think that is a good question - although it has been very convenient during the bring-up phase to have it in
an external repository, it seems to me that it would be a better solution to integrate at least
libpthread_workqueue, as you suggest. Libkqueue seems usable on its own merits, which suggests that it
should remain stand-alone.

libpthread_workqueue is a fairly limited codebase and even though some refactoring/packaging may be
required, it shouldn’t be too much work to integrate it nicely. 

Even though I do think it should be considered if it would be beneficial to use some other abstraction
instead of the pthread_workqueue interface for the non-Mac OS X parts, it is not obviously required at
present - the current approach seems to work quite well so far. 

If there would be a clear benefit, at least it is only in ~10 places that libdispatch references the
pthread_workqueue API:s, so any such hypothetical #ifdefs would at least be limited in scope.

Another aspect of this though, would be if one wants to bring libpthread_workqueue further in terms of
‘cooperation’ between multiple clients of the library (as discussed between you and Mark a long time
ago). 

Personally I think that would be desired an beneficial, even taking the DOS problems brought up then into
consideration, at least as an optional input to the thread scale rampup/down logic.

For reference: currently libphtread_workqueue takes into account several inputs for deciding when to
gracefully ramp up/down the number of threads used (e.g. number of available cores, current system load
average, the number of currently runnable threads/LWP:s in the process, how long (and how many) threads
that are idle, ...) - but it is only working really well within the scope of a single process, since the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Heily | 13 Apr 2011 06:03

Re: porting status

On 04/11/2011 02:12 PM, Jordan K. Hubbard wrote:
>
>
> Hi guys,
>
> Just out of curiosity, is this going to essentially be the "preferred
> interface" (libpthread_workqueue + libkqueue) going forward for
> non-MacOSX platforms?  Don't get me wrong:  Anything which requires the
> fewest contortions in libdispatch to work is great for us since it won't
> "cruft up" the code with lots of #ifdefs, but at the same time if there
> are better ways to plumb at least the pthread_workqueue stuff such that
> we can be more agile on other platforms, it would be interesting to at
> least *have* that architectural discussion.  Such discussion may or may
> not lead anywhere, but it seems like we're starting to gain traction on
> other platforms and it makes me curious as to how well we're "impedance
> matched" to them.  Any comments on that?
>

Hi Jordan,

It would be nice to simplify the process of building and distributing 
libdispatch.

I would like to see libdispatch import a private copy of the stable releases 
of libkqueue and libpthread_workqueue. They could be placed in a contrib/ 
subdirectory, for example. This would allow the libdispatch autoconf script 
to "solve" any missing dependencies by building the additional libraries 
inside of the contrib/ subdirectory. The extra libraries could be combined 
with libdispatch to produce a single libdispatch.so file.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joakim Johansson | 13 Apr 2011 07:36
Favicon

Re: porting status

That would be very nice of course, allowing for a one-stop-shop to get libdispatch up and running - should
help lower the barrier of entry to using it quite a bit.

Joakim

On 13 apr 2011, at 06.03, Mark Heily wrote:

> I would like to see libdispatch import a private copy of the stable releases of libkqueue and
libpthread_workqueue. They could be placed in a contrib/ subdirectory, for example.
Permalink | Reply | 1 comment |
headers
David Leimbach | 13 Apr 2011 16:15
Picon

Re: porting status

+1

Sent from my iPhone

On Apr 12, 2011, at 10:36 PM, Joakim Johansson <jocke@...> wrote:

> That would be very nice of course, allowing for a one-stop-shop to get libdispatch up and running - should
help lower the barrier of entry to using it quite a bit.
> 
> Joakim
> 
> On 13 apr 2011, at 06.03, Mark Heily wrote:
> 
>> I would like to see libdispatch import a private copy of the stable releases of libkqueue and
libpthread_workqueue. They could be placed in a contrib/ subdirectory, for example.
> 
> _______________________________________________
> libdispatch-dev mailing list
> libdispatch-dev@...
> http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Permalink | Reply | 0 comments |
headers
Brent Fulgham | 14 Apr 2011 22:37
Picon

libdispatch on Windows

Hi Everyone,

A few weeks ago, Kevin posted on the mailing list in response to
Marius Zwicker's report of his Linux/Windows port:
 "It's great that you have enough interest in the libdispatch project
to work on a port to Linux and Win32. If you weren't aware, we already
have Linux and partial Win32 support in the primary libdispatch source
repository. I would encourage you to contribute modifications to the
primary project rather than attempt a complete rewrite."

I was wondering if there is any information on how to build or test
the Windows code?  I'd like to contribute to moving that project
forward.

Thanks,

-Brent
Permalink | Reply | 1 comment |
headers
Marius Zwicker | 14 Apr 2011 23:04
Picon

Re: libdispatch on Windows

Hi Brent,

Just have a look at the current xdispatch trunk at
http://opensource.mlba-team.de/svn/xdispatch/trunk/core. Starting with version 0.4 I started to
integrate the original libdispatch sources - on windows as well. It is already completely compiling when
using mingw, while msvc support is pending. At the moment we are busy implementing libkqueue for windows.
After that we can try to get all tests passing.

Within the sources at macosforge.org you can find some partial implementations using windows semaphores only.

I'd welcome any patches regarding msvc or for improving the overall quality. As soon as we have the majority
of the tests passing I hope to sent patches back to libdispatch.macosforge.org

Marius

Am 14.04.2011 um 22:37 schrieb Brent Fulgham <bfulgham@...>:

> Hi Everyone,
> 
> A few weeks ago, Kevin posted on the mailing list in response to
> Marius Zwicker's report of his Linux/Windows port:
> "It's great that you have enough interest in the libdispatch project
> to work on a port to Linux and Win32. If you weren't aware, we already
> have Linux and partial Win32 support in the primary libdispatch source
> repository. I would encourage you to contribute modifications to the
> primary project rather than attempt a complete rewrite."
> 
> I was wondering if there is any information on how to build or test
> the Windows code?  I'd like to contribute to moving that project
> forward.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Fulgham | 15 Apr 2011 21:04
Picon

libdispatch with Visual Studio

I spent a few minutes yesterday playing with the libdispatch sources
to see how far I could get building under Visual Studio.  As expected,
it choked when presented with various useful gcc extensions, such as
named structure initializers, differences in macro handling, and so
forth.

All of these differences are fairly easily resolved, with the
exception of the gcc-specific 'typeof' operator.  I'm not sure how to
provide similar behavior under the Visual C++ compiler, as I don't
think it has a mechanism to determine the static type of an expression
at runtime.

Can anyone comment on how this is resolved for the Apple build of
libdispatch (i.e., the version that ships with Safari/WebKit)?

Thanks,

-Brent
Permalink | Reply | 3 comments |

Gmane