# Using libfdb in unikernel without preemptive threading **URL:** \ **Category:** Using FoundationDB\ **Created:** [February 9, 2019, 9:41am UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123 "2019-02-09T09:41:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![andreas](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@andreas](https://forums.foundationdb.org/u/andreas)\ **Post date:** [February 9, 2019, 9:41am UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/1 "2019-02-09T09:41:26Z")
I’m interested in using `libfdb` in the context of [MirageOS](https://mirage.io/), a library operating system for constructing secure, high-perfomance unikernels. The challenge is that MirageOS is fully event-driven, with no support for preemptive threading. This means I cannot construct a thread for running [`fdb_run_network`](https://apple.github.io/foundationdb/api-c.html#c.fdb_run_network) as instructed in the documentation: > Unless your program is entirely event-driven based on results of asynchronous functions in this API and has no event loop of its own, you will want to invoke this function on an auxiliary thread (which it is your responsibility to create). I assume both MirageOS and `libfdb` ultimately end up dispatching to `select` or `epoll`, so in a sense, the approaches should be compatible. The question is whether the two event-loops of `libfdb` and MirageOS can be bridged/consolidated somehow. Any input on how to achieve this would be greatly appreciated. Thanks in advance! 🙏 ---
**Author:** ![markus.pilman](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/markus.pilman/32/379_2.png) [@markus.pilman](https://forums.foundationdb.org/u/markus.pilman)\ **Post date:** [February 10, 2019, 5:33pm UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/2 "2019-02-10T17:33:11Z")
My OCaml knowledge is very limited, so I am not sure whether this is possible and if it is, how it would be. The good news is, that fdb is single threaded and completely event driven. So in theory this would be great. However, libfdb\_c (which is the C language bindings) uses a dispatch thread. Therefore, you probably can’t use libfdb\_c. Therefore you would need to implement a new flow-aware OCaml binding. As I see it, there are two ways of achieving what you want: 1. You can try to execute your OCaml tasks in the context of the flow main loop. I know that this is possible in Python (I did this once some time back as an experiment). This would probably be the preferred way. 2. You can try to implement a new `run_once` method in and execute this in the OCaml main loop. Either solution would require you to program directly against the C++ API or write a new C API. If you program against C++, it will come with all the caveats of linking directly against C++ (but you should be mostly fine as long as you recompile for every version you are going to use). Sadly, none of these two options can be implemented quickly or eaily… ---
**Author:** ![andreas](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@andreas](https://forums.foundationdb.org/u/andreas)\ **Post date:** [February 11, 2019, 2:45pm UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/3 "2019-02-11T14:45:31Z")
Thanks for your input @markus.pilman! Your proposed solutions make sense, though I agree they are probably quite costly to implement. I also considered implementing `INetwork` specifically for MirageOS, but that seems like a sizeable task as well. ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [February 12, 2019, 12:35am UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/4 "2019-02-12T00:35:47Z")
Even if you worked out how to stitch MirageOS and FDB’s event loops together, I suspect you’d also run into trouble with the multi version client library requiring `dlopen()` support? I imagine you’re missing a dynamic linker as well. ---
**Author:** ![markus.pilman](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/markus.pilman/32/379_2.png) [@markus.pilman](https://forums.foundationdb.org/u/markus.pilman)\ **Post date:** [February 12, 2019, 3:43am UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/5 "2019-02-12T03:43:33Z")
You could use directly use NativeAPI. In that case you wouldn’t be able to use the multiversion client anyways… This would currently mean that you would need to upgrade all clients at the same time you upgrade the servers. If we ever get downwards compatible clients, this would be easier. ---
**Author:** ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)\ **Post date:** [February 12, 2019, 6:43am UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/6 "2019-02-12T06:43:44Z")
The multiversion client also runs through the C bindings and starts a thread for the other version’s event loop, so that would be another obstacle to its use. ---
**Author:** ![andreas](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@andreas](https://forums.foundationdb.org/u/andreas)\ **Post date:** [February 19, 2019, 12:05pm UTC](https://forums.foundationdb.org/t/using-libfdb-in-unikernel-without-preemptive-threading/1123/7 "2019-02-19T12:05:07Z")
Thanks for the input. It sounds quite challenging to pull this off, so I’ll leave it be for now.