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

Reply via email to