I think you can try to have native threads by running a separate instance of the Chicken runtime for each thread, but are you sure that you will really achieve a significant speedup over Unix processes and/or MPI? It's not the early nineties anymore... I suggest prototyping code and running real-world benchmarks first. But thanks for your efforts on semaphores. I think wrapping the C API is the easy part, you can probably just use c-pointer for the sem_t type. I am guessing the hard part would be ensuring consistent semantics between Unix and the pinnacle of free-market capitalism, Microsoft Windows.
On Sat, May 4, 2013 at 8:39 AM, Dan Leslie <d...@ironoxide.ca> wrote: > Yah, I meant sem_wait et al. > > I was under the impression that synch and mailbox rely on srfi-18 > structures, which would make them 'green' threads-only and not particularly > suitable for multi process synchronization. > > Relatedly, is anyone poking at implementing native threads? > I've been digging around a bit but haven't had much time to progress very > far. > > I'm hesitant to take responsibility for writing a semaphore egg, but what > the hell. I'll start something on GitHub this weekend. > > -Dan > > > On 5/3/2013 4:22 PM, Ivan Raikov wrote: > > Are you talking about POSIX semaphores, sem_wait(3) and friends, or just > the general semaphor data structure? If the former, then the Chicken > developers are eagerly awaiting your patches ;-) If the latter, take a look > at the synch and mailbox eggs. They have mutex-like functionality that can > be used in place of proper semaphores. > > Ivan > On May 4, 2013 7:59 AM, "Dan Leslie" <d...@ironoxide.ca> wrote: > >> I was just poking through posix, posix-shm, posix-utils, and >> posix-extras and it seems that none of them implement semaphores! >> >> Am I missing something, or is this actually the case? >> >> -Dan >> >> On 5/3/2013 3:26 PM, Ivan Raikov wrote: >> >> Hello, >> >> I really strongly advise _against_ using SRFI-4 vectors for 4G files, >> as I have experienced serious performance issues even with vectors of a few >> million elements. If your C code is to be linked with your Chicken code, >> you can pass the pointer to your data from C to Scheme and use SRFI-4 >> foreign pointers to access it (see unit lolevel for details). If the C code >> is running as a separate process, you could try using posix-shm to create >> shared memory between processes and then use foreign pointers in the >> Chicken process. >> >> Ivan >> On May 4, 2013 3:04 AM, "Pedro Melendez" <pmelen...@pevicom.com> wrote: >> >>> >>> Hi all, >>> >>> Sorry if this question is obvious, but I couldn't find what I were >>> looking for in the documentation so maybe you guys can help me. >>> >>> I am developing a prototype of a server that would serve 3D seismic >>> images across the network. This task requires to process big files (~4 GB) >>> with existing C code that is desirable to maintain. I plan to write the >>> server itself in Chicken scheme but I would need to maintain the existing >>> code in C that opens and process those files. >>> >>> Giving the size of the file, I want to share the memory space between >>> C and Chicken and avoid copying values between areas. Is that even >>> possible? Anyone has an idea on how can I address this? >>> >>> Thanks in advance! >>> >>> Pedro >>> >>> -- >>> T: +1 (416) - 357.5356 >>> Skype ID: pmelendezu >>> >>> >>> >>> _______________________________________________ >>> Chicken-users mailing list >>> Chicken-users@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/chicken-users >>> >>> >> >> _______________________________________________ >> Chicken-users mailing >> listChicken-users@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/chicken-users >> >> >> >
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users